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The  Battlefield  Information  Systems  Technical  Area  of  the  Army  Research 
Institute  (ARI)  is  concerned  with  helping  users  and  operators  cope  with  the 
ever  increasing  complexity  of  the  battlefield  automated  systems  by  which  they 
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related  to  interactions  with  command  and  control  centers,  and  on  issues  of 
system  design  and  development.  Research  is  addressed  to  such  areas  as  user- 
oriented  systems,  software  development,  information  management,  staff  opera¬ 
tions  and  procedures,  decision  support,  and  systems  integration  and  utiliza¬ 
tion. 


An  area  of  special  concern  in  user-oriented  systems  is  the  improvement 
of  the  user-machine  interface.  Lacking  consistent  design  principles,  current 
practice  results  in  a  fragmented  and  unsystematic  approach  to  system  design, 
especially  where  the  user/operator-system  interaction  is  concerned.  Despite 
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system.  The  current  effort  is  dedicated  to  the  development  of  a  comprehensive 
set  of  human  factors  guidelines  and  evaluation  criteria  for  the  design  of 
user/operator  transactions  with  battlefield  automated  systems.  These  guide¬ 
lines  and  criteria  are  intended  to  assist  proponents  and  managers  of  battle¬ 
field  automated  systems  at  each  phase  of  system  development  to  select  the 
design  features  and  operating  procedures  of  the  human-computer  interface 
which  best  match  the  requirements  and  capabilities  of  anticipated  users/ 
operators . 

Research  in  the  area  of  user-oriented  systems  is  conducted  as  an  in-house 
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is  responsive  to  requirements  of  Army  Project  2Q263744A793,  Human  Performance 
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DESIGN  GUIDELINES  FOR  USER  TRANSACTIONS  WITH  BATTLEFIELD 
AUTOMATED  SYSTEMS:  PROTOTYPE  FOR  A  HANDBOOK 

EXECUTIVE  SUMMARY 


Requirement: 

To  develop  a  methodology  that  provides  a  framework  and  format  for  a  com¬ 
prehensive  set  of  human  factors  guidelines  for  the  design  of  user  transactions 
with  battlefield  automated  systems  for  use  by  human  factors  specialists  and 
system  proponents ,  managers,  and  developers. 

Procedure: 

To  meet  the  requirements  stated  above,  a  three  phase  research  program  was 
initiated.  Phase  I  was  devoted  to  defining  human  factors  requirements  for 
battlefield  automated  systems  and  establishing  a  framework  within  which 
guidelines  could  be  organized.  In  Phase  II,  the  technical  data  base  was 
further  developed  through  search  of  the  military  and  civilian  literature  related 
to  user/operator  transactions  with  automated  data  processing  systems  and  a  pro¬ 
totype  handbook  of  guidelines  was  developed.  When  guidelines  were  available 
in  the  literature,  they  were  reworded  as  necessary  for  consistency  of  expression 
and/or  modified  to  conform  to  the  newly  established  framework.  Other  guide¬ 
lines  were  written  on  the  basis  of  project  staff  experience,  modulated  by  the 
results  of  the  analytic  activities  during  Phase  I. 

During  Phase  III,  the  provisional  guidelines  were  applied  to  the 
soldier /machine  interfaces  of  two  battlefield  automated  system  developmental 
programs,  each  at  a  different  stage  of  development.  These  application  efforts 
provided  the  basi  for  refinement  of  the  format  and  methodology  for  developing 
such  guidelines.  Modifications  were  made  to  the  guidelines  and  they  were 
republished. 

Findings : 

Guidelines  in  the  literature  were  plentiful  in  the  areas  of  data  entry 
and  error  handling.  There  was  also  substantial  information  on  coding  ai.u 
display  formats.  Thus,  approximately  half  of  the  guidelines  were  written 
by  the  project  staff. 

Utilization  of  Findings: 

The  methodology,  conceptual  framework  and  format  of  the  guidelines 
developed  in  the  course  of  this  project  appear  to  provide  a  productive 
approach  to  inproving  the  process  of  "technological  transfer"  of  data  from 
human  factors  researchers  to  other  members  of  system  design  teams  of 
battlefield  automated  systems.  The  development  of  an  officially  sanctioned 
set  of  guidelines  will  require  interaction  and  coordination  between  many 
Army  agencies.  This  handbook  will  provide  a  stimulus  for  such  interaction, 
in  the  meantime,  judicious  application  of  these  guidelines  will  improve 
the  effectiveness  of  the  soldier/machine  interface  of  future  systems 
and  will  promote  the  behavioral  interoperability  of  these  systems,  i.e., 
increase  the  degree  to  which  skills  and  knowledge  can  be  transferred  from 
one  system  to  another. 
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INTRODUCTION 


This  document  is  the  final  product  of  a  three-phase  project  to  develop 
a  framework  and  format  for  a  handbook  of  human  factors  guidelines  for  use  by 
Army  system  developers  and  designers,  system  manufacturers,  and  particularly, 
human  factors  specialists  serving  as  members  of  design  teams  of  battlefield 
automated  systems. 

The  first  phare  of  the  project  developed  a  baseline  of  characteristics, 
problems  and  deficiencies  in  the  soldier/machine  interfaces  of  existing  systems. 
This  baseline  provided  a  foundation  for  the  second  phase  which  comprised  a 
literature  survey  and  preparation  of  a  preliminary  version  of  a  design 
guidelines  handbook. 

The  object  of  the  third  phase  was  to  evaluate  the  utility  and  usability 
of  the  initial  version  of  the  handbook.  Two  battlefield  automated  system 
developmental  programs,  each  at  a  different  stage  within  the  Army  acquisition 
process,  served  as  test  cases  of  evaluating  the  preliminary  handbook.  The 
first,  the  Vehicle  Integrated  Defense  System  -  Data  Management  System  (VDIS-DMS) 
is  under  development  at  the  US  Army  Tank  and  Automotive  Command  (TACOM) .  Its 
purpose  is  to  provide  a  data  management /display  system  to  coordinate  the  threat 
warning  Lensors,  threat  reaction  devices  and  crew  interaction  sub-systems  of 
tanks  and  other  armored  vehicles.  The  second  is  the  Vetronics  Program  (also 
at  TACOM)  which  has  as  its  object  the  definition  of  the  system  architecture 
required  to  support  the  total  integration  of  armored  vehicle  electrical/electronic, 
informational  and  display  systems  and  technology  within  the  context  of  the 
AirLand  Battle  2000  concept.  The  results  of  these  two  evaluations  are  reported 
separately  in  ARI  Research  Note  84-28.  These  two  application  efforts  provided 
the  basis  for  refinement  of  the  format  and  methodology  for  developing  such 
guidelines.  A  summary  of  the  project  to  develop  design  guidelines  is  reported 
in  ARI  Research  Note  84-29,  and  the  refinements  have  been  incorporated  into  this 
latest  version  of  the  prototype  for  a  handbook. 

Comments  and  suggestions  are  invited  with  regard  to  the  format  and  language 
of  the  handbook  and  the  readability,  understandability  and/or  value  of  this 
approach  to  guideline  development  for  system  developers,  system  designers, 
human  factors  specialists  and  other  potential  user  groups.  Address  any 
comments  to  the  Commander,  Army  Research  Institute,  ATTN:  PERI-SP,  5001 
Eisenhower  Avenue,  Alexandria,  VA  22333-5600. 
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Background 

The  US  Army  is  turning  increasingly  to  the  use  of  battlefield  automated 
systems  to  meet  its  anticipated  mission  requirements.  More  than  70  separate 
automated  systems  for  Corps  area  deployment  are  currently  in  a  production, 
development  or  concept  definition  phase. 

It  has  long  been  recognized  that  the  development  of  complex  systems  must 
take  into  account  the  characteristics  of  the  expected  users.  Over  the  past 
40  years  an  expanse  of  knowledge  has  accumulated  on  the  relationships  among 
operator  characteristics,  system  design  and  system  performance.  This  infor¬ 
mation,  although  widely  scattered,  provides  a  basis  for  developing  guidelines 
for  human-computer  interaction.  Although  this  knowledge  has  been  incorporated 
into  various  system  design  handbooks  and  utilized  in  hardware  design  and  develop¬ 
ment,  most  efforts  have  focused  on  "human  engineering"  data,  reflecting  the 
impact  of  physical  characteristics  of  a  piece  of  equipment  on  operator 
performance.  However,  a  major  source  of  difficulty  in  designing  effective 
battlefield  automated  systems  devolves  from  less  tangible  aspects  of  user-  . 
system  relationships.  Thus,  critical  quest lore  concerning  user  related  character¬ 
istics  (such  as  query  language,  display  format,  data  base  structure,  etc), 
as  well  as  issues  of  skill  requirements  and  training,  have  remained  unanswered. 

In  addition,  it  has  been  tacitly  assumed  that  the  advent  of  battlefield 
automation  would  relieve  the  user/operators  of  some  of  their  difficult  tasks 
and  would  thus  reduce  the  number  of  personnel,  if  not  the  skill  levels,  required. 
Unfortunately,  as  has  often  been  the  case  in  non-military  applications,  the 
opposite  result  has  been  observed;  effective  exploitation  of  the  complex 
technology  of  automation  requires  even  greater  skill  levels.  This  problem 
has  been  compounded  in  the  Army  by  the  progressive  mismatch  between  the  level 
and  number  of  high  skill  positions  required  in  automated  systems  and  the  human 
resources  available. 

The  skill/demand  mismatch  is  due  in  part  to  the  fact  that  the  equipment/ 
procedural  configuration  of  existing  and  projected  systems  have  been  devised 
without  coordination  among  proponents  of  different  systems.  As  a  result, 
very  little  of  the  skill  and  know-how  accrued  from  experience  with  one  system 
can  be  transferred  to  other  systems.  Many  of  the  procedures  employed 
in  the  operation  of  various  systems  are  basically  similar.  Yet  from  the 
user's  perspective,  each  system  is  a  new  situation  with  very  little  carryover 


or  transfer  from  previous  exposure  to  other  systems.  While  it  may  be  too 
early  to  establish  absolute  "standards''  for  many  system  parameters,  a  measure 
of  consistency  would  go  a  Ion?  way  toward  increasing  effectiveness,  reducing 
personnel  costs  and  making  battlefield  automated  systems  more  approachable  to 
users  and  operators. 

In  the  long  run,  effective  utilization  of  battlefield  automated  systems 
will  depend  largely  upon  the  availability  of  standardized  procedures  and  tech¬ 
niques  for  user-system  transactions.  Howe-sr,  the  very  nature  of  the  material 
acquisition  process  of  military  systems  makes  such  standardization  difficult. 
The  constraints  imposed  by  tight  schedules  and  limited  funds  require  the 
project  manager  to  concentrate  on  a  system  that  succeeds  in  achieving  certain 
physical  specifications; ■  Concerns  about  interoperability  with  other  systems, 
total  life  cycle  costs  or  other  meta-system  factors  are  secondary.  This  is 
particularly  true  with  respect  to  those  aspects  of  system  design  and  operation 
that  fall  within  the  behavioral  domain. 

Features  that  impact  the  users  of  automated  information  processing  systems 
such  as  the  data  base  structure,  data  entry  method,  display  format,  command/ 
query  language,  terminology,  error  feedback  and  recovery  procedures,  helps/ 
prompts,  etc.,  are  determined  by  the  particular  configuration  of  hardware 
(and  accompanying  software,  if  any)  that  meets  certain  costs  and  engineering 
criteria.  The  extent  to  which  the  users'  cognitive,! mnemonic,  perceptual 
and  other  behavioral  capacities  are  unnecessarily  burdened  or  stressed  by 
deficiencies  in  any  of  these  features  is  considered  peripherally,  if  not 
all. 

Part  of  the  reason  is  the  paucity  of  information  that  a  concerned  system 
designer  ean  use  to  (1)  identify  those  features  of  a  system  that  influence 
user  performance,  and  (2)  obtain  guidance  as  to  how  to  incorporate  (or  avoid) 
those  features  that  will  increase  (or  decrease)  operator/user  performance. 
Notable  exceptions  are  the  sets  of  guidelines  produced  by  Engel  and  Granda 
(1975)  and  Smith  and  Aucella  (1983). 

Objectives 

One  of  the  major  aims  of  the  present  project  was  to  devise  a  format 
for  recasting  ouch  of  the  previously  generated  human  factors  data  into 
a  form  that  makes  it  more  digestible  to  other  members  of  the  system 
design  team. 
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A  second  major  objective  is  to  propound  end  promote  the  concept  of 
Behavioral  Interoperability.  Interoperability  is  pursued  as  a  design  goal 
with  respect  to  coaouni cat ions,  electrical  characteristics,  plugs/connectors  and 
other  physical  attributes  of  Information  procesaing  systems.  It  would  appear 
productive  to  extend  the  concept  to  the  behavioral  domain. 

To  achieve  behavioral  interoperability  it  would  be  necessary  to  (1) 
identify  and  describe  in  operational  terms  those  aspects  of  human/computer 
Interfaces  and  interactions  that  are  functionally  similar;  (2)  create  universal 
"task  modules"  for  executing  common  transactions  (see  Table  A  for  examples) 
as  well  as  a  body  of  recommended  (standardized)  interface  design  features  and 
operating  procedures  derived  through  the  application  of  human  factors  concepts 
and  principles,  or  where  necessary,  empirical  research;  and  (3)  provide 
guidelines  to  other  system  design  specialists  that  are  explicit  (rather 
than  exhortatory)  and  are  indexed  and  expressed  in  a  form  compatible  with 
their  needs. 

Table  A:  Examples  of  Human-Computer  Transaction  Types 

1.  Specify  a  file  to  work  with 

2.  Display  a  file 

3.  Store  a  file 

4.  Delete  a  file 

5.  Copy  a  file 

6.  Create  a  new  file 

7.  Sort  a  file 

8.  Add  information  to  a  file 

v.  Define  the  format  of  output 

Designing  for  behavioral  interoperability  between  information  processing 
systems  would  have  two  important  benefits.  First,  It  would  minimize  the  amount 
of  task-specific  or  equipment-specific  training  that  a  user  would  need  to 
interact  with  the  system  upon  first  encounter.  Second,  it  would  minimize  the 
skill  level  required  to  exercise  the  complex  data  processing  capabilities  of 
the  system  by  reducing  the  number  and  complexity  of  operator  actions. 
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As  an  initial  step,  data  regarding  12  tactical  information  processing  systems 
were  obtained  via  documentational  analysis  or  interviews  with  authoritative 
members  of  system  design  teams.  Included  in  the  survey  were  information  pro¬ 
cessing  systems  designed  for  intelligence  applications  (Army,  Marine,  Air  Force), 
command  and  control,  artillery  fire  control  and  logistics. 

Battlefield  automated  systems  have  a  large  number  of  features  that  Impact 
on  human  performance.  In  order  to  concentrate  limited  resources  and  minimize 
intrusion  into  the  busy  schedules  of  personnel  from  whom  system  data  were 
solicited,  the  survey  was  deliberately  limited  in  scope.  Eight  "design  features" 
that  significantly  impact  the  soldier/machine  interface  and  are  common  to  all 
battlefield  automated  systems  were  selected  somewhat  arbitrarily.  They 
represent  a  pragmatic  collection  of  design  feature  categories  requiring 
priority  attention  rather  than  the  elements  of  a  comprehensive  taxonomy  of 
soldier /machine  interface  issues. 

For  the  sake  of  consistent  exposition,  the  guidelines  data  associated  with 
all  of  the  design  feature  categories  were  assembled  within  a  single,  structured 
format.  This  format  was  designed  to  aid  system  developers  and  system  engineers 
in  selecting  appropriate  design  features  for  particular  systems  and,  at  the 
same  time,  to  increase  the  degree  of  behavioral  interoperability  between 
various  systems.  Accordingly,  each  set  of  guidelines  was  formulated  in  terms 
of  the  elements  shown  in  Table  2. 

In  developing  the  specific  guidelines  presented  under  the  "Recommendations" 
and  "Advisory  Comments"  topics  in  each  subsection,  heavy  use  was  made  of 
material  presented  by  Engel  and  Granda  (1975),  Ramsey,  Atwood,  and  Kirshbaum 
(1978),  Ramsey  and  Atwood  (1979),  Smith  (1979,  1980),  and  Williges  and  Williges 
(1981).  The  majority  of  these  guidelines  were  reworded  or  entirely  rewritten 
to  achieve  consistency  of  style  in  the  handbook,  to  provide  greater  emphasis, 
to  sharpen  their  focus  on  specific  transaction  types,  to  remove  psychological 
jargon,  or  to  increase  their  clarity  of  expression.  They  were  then  distributed 
according  to  the  organizing  framework  in  Table  1  and,  in  the  case  of  "Advisory 
Comments,"  according  to  the  techniques  described  under  "X.X.4  Methods." 

Many  guideline  areas  in  Table  1  are  not  addressed  in  the  civilain  or  mil¬ 
itary  literature,  or  are  addressed  only  generally  or  sparsely.  For  these 
areas,  guidelines  were  developed  on  the  basis  of  the  knowledge  and  experience 
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of  the  project  staff.  Guidelines  for  individual  sections  of  the  prototype 
handbook  were  prepared  by  different  personnel  and  then  reviewed  by  other 
personnel.  Differences  of  opinion  were  resolved  through  discussion. 

Guidelines  in  this  category  comprise  perhaps  half  the  total  v^ume  of 
the  prototype  handbook.  Such  guidelines,  of  course,  are  as  yet  neither  sup¬ 
ported  nor  challenged  by  the  results  of  research,  and  inevitably  they  reflect 
the  collective  prejudices  of  the  project  staff.  Nonetheless,  they  reflect 
application  in  human-computer  interface  development  efforts  on  which  project 
personnel  have  worked.  More  importantly,  they  also  reflect  solutions  devised 
for  problems  and  deficiencies  observed  during  the  analytical  activities  of  the 
first  phase.  They  are  therefore  believed  to  represent  reasonable  guidance  for 
the  design  of  user-computer  transactions  with  battlefield  automated  systems. 

Those  readers  who  wish  to  consult  the  literature  surveyed  in  preparation 
for  developing  these  guidelines  will  find  a  supplemental  Bibliography  at  the 
end  of  this  document.  They  would  be  well  advised,  however,  to  begin  with  the 
excellent  review  by  Ramsey  and  Atwood  (1978),  and  the  monumental  annotated 
bibliography  compiled  by  Ramsey,  Atwood,  and  Kirshbaum  (1978). 


Table  1.  Organizing  Framework  for  Guidelines  and  Criteria  for  this  Document 


1 .  Control  Methods 

1.1  Alphanumeric  Control  Methods 

1.2  Graphics  Control  Methods 

1.3  HELPS 

2 .  Display  Techniques 

2.1  Alphanuneric  Displays 

2.2  Graphics  Displays 

2.3  Selective  Highlighting 

3.  Data  Entry  and  Handling 

3.1  Information  on  Legal  Entries 

3.2  Unburdening  of  Input 

3.3  interrupts  and  Work  Recovery 

4.  Massage  Composition  Aids 

4.1  Alphanumeric  Messages 

4.2  Graphics  Displays 

5.  Data  Retrieval  Assistance 

5 .1  Query  Method 

5.2  Query  Structure 

6.  Symbology  and  Terminology 

6.1  Symbols  and  Symbol  Sets 

6.2  Standard  Terms 

6.3  Abbreviations  and  Codes 

6.4  Full  Language 

6.5  Glossaries 

7.  Error  Handling 

7.’  Error  Feedback 

7.2  Error  Cor rec \.i ori/F-eco very 

8.  User/Operator  Configurations 


Table  2.  Organization  of  the  Topics  in  Each  Subsection  of  the  Guide¬ 
lines  and  Criteria. 


X.X.l  DEFINITION.  Defines  the  category  of  guide¬ 
lines  and  criteria  covered  in  the  subsection. 

X.X.2  APPLICATIONS.  Describes  the  situations  to 
which  guidelines  and  criteria  in  the  sub¬ 
section  apply.  Examples  are  provided  to 
illustrate  the  applications. 

X.X.3  BENEFITS.  Describes  the  ways  in  which  utili¬ 
zation  of  the  guidelines  will  enhance  system 
performance.  Descriptions  of  benefits,  inter¬ 
preted  in  terms  or  the  specific  system's 
characteristics,  can  be  translated  into  evalua¬ 
tion  criteria. 

X.X.4  METHODS.  Describes  specific  methods  for 

implementing  the  guidelines  in  the  subsection. 
Examples  are  provided  liberally  to  clarify 
each  method. 

X.X.5  RECOMMENDATIONS.  Contains  specific  guidelines 
which  apply  across  all  methods  in  the  sub¬ 
section.  The  first  recommendation  in  each 
subsection  is  a  matrix  of  applications  versus 
methods,  suggesting  specific  methods  to  use 
for  each  application. 

X.X.6  ADVISORY  COMMENTS.  Contains  specific  guide¬ 
lines  for  each  method  in  the  subsection. 
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Using  This  Handbook 


The  reader  consulting  this  prototype  handbook  about  a  particular  issue  in 
the  design  of  the  soldier-system  interface  will  probably  gain  the  greatest 
utility  by  following  these  steps: 

1.  Check  the  Table  of  Contents  to  locate  the  major  section  that 
appears  most  likely  to  contain  the  desired  information. 

2.  Read  the  first  page  of  the  section;  it  provides  an  overview 
of  the  section  and  briefly  describes  each  subsection. 

3.  Turn  to  the  subsection  that  appears  to  be  most  appropriate 

to  the  issue  of  concern.  (Table  1  lists  the  sections  and  sub¬ 
sections  . ) 

4.  Read  the  DEFINITION  of  that  subsection  to  ensure  that  it  does 
indeed  contain  the  desired  information  (Table  2  lists  the 
six  topics  in  each  subsection.) 

5.  Examine  the  APPLICATIONS  and  locate  the  one  of  greatest 
interest, 

6.  Take  a  moment  to  read  the  BENEFITS  topic.  It  explains  why 
guidelines  in  this  subsection  are  useful  in  interface  design. 

This  topic  also  provides  the  basis  for  developing  evaluation 
criteria,  given  information  about  specific  system  character¬ 
istics  . 

7.  Read  about  the  METHODS  that  are  used  to  implement  the  various 
applications  in  the  subsection. 

8.  RECOMMENDATIONS  provide  guidelines  that  apply  to  all  the  methods 
described  in  the  subsection.  The  first  recommendation  is  a 
matrix  suggesting  the  preferred  method  to  use  for  each  appli¬ 
cation.  Check  the  matrix  for  the  best  method  for  your 
particular  application,  then  read  the  remaining  recommendations 
for  general  guidance. 

9.  Finally,  consult  the  ADVISORY  COMMENTS  regarding  the  selected 
method.  These  are  recommendations  focused  on  each  specific 
method,  and  they  should  not  be  ignored  in  designing  the  soldier- 
system  interface. 


SECTION  1 .  CONTROL  METHODS 


Guidelines  in  this  category  deal  with  methods  for  allowing  users/opera¬ 
tors  to  control  the  processes  of  the  hardware  and  software  components  of  the 
system.  The  guidelines  discuss  what  methods,  or  combinations  of  methods, 
are  most  appropriate  for  given  combinations  of  user  types,  hardware  and 
software  characteristics,  and  environmental  factors.  Three  aspects  of  con¬ 
trol  methods  are  considered: 

1.  Alphanumeric  Control  Methods,  characterized  by  a  requirement 
for  the  user/operator  to  learn  and  apply  a  language  which  the 
system  "understands." 

2.  Graphics  Control  Methods,  techniques  employing  imagery,  sym¬ 
bology,  and  pictorial  representation  by  which  users/operators 
may  define  desired  system  operations. 


HELPs ,  methods  for  presenting  information  and  instruction  to 
the  user/operator  which  "cue"  system  operation. 


1.1  Alphanumeric  Control  Methods 


1.1.1  DEFINITION 

Alphanumeric  control  methods  are  dialog  types  made  up  of  alphabetic, 
numeric,  and  usually  also  the  standard  grammatical  symbol  sets,  by  which 
users/operators  communicate  their  instructions  to  the  computer  through  the 
computer  terminal. 
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1.1.2  APPLICATIONS  FOR  ALPHANUMERIC  CONTROL  METHODS 


Alphanumeric  control  methods  are  used  to  control  the  operation  of  ADP 
systems . 
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1.1.4  METHODS  FOR  ENTERING  ALPHANUMERIC  CONTROLS 

a.  Question  and  answer  dialog/  in  which  the  computer  system  asks 
the  user/operator  specific  questions.  In  the  simplest  form  of 
this  type  of  dialog,  the  user/operator  may  respond  only  with 
"Y(ES) "  or  "N (O) . "  In  more  complex  forms,  the  user/operator 
may  be  required  to  respond  with  a  number  or  a  code  for  a  com¬ 
mand. 


00  rOU  WISH  TO  RETRIEVE  INFORMATION?  ~> 
DO  VOU  WISH  TO  CREATE  A  NEW  FILE?  -.» 
DO  you  WISH  TO  STORE  INFORMATION?  ~> 


b.  Form  filling,  in  which  the  user/operator  fills  out  a  form  or 
questionnaire  presented  at  the  terminal.  The  entries  in  the 
"blanks"  may  be  words,  codes,  numbers,  or  merely  symbols  (e.g., 
"checkmarks")  to  indicate  that  the  user/operator  wishes  to  per¬ 
form  the  operation  displayed  on  the  screen. 
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Fixed  function  keys,  in  which  the  user/operator  presses  a  special 
key  on  a  terminal  keyboard  to  indicate  to  the  computer  that  a 
particular  operation  should  be  performed.  The  keys  are  labeled 
with  the  operations  which  the  system  is  to  perform. 
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Variable  function  keys,  in  which  the  user/operator  presses  a 


special  key  to  indicate  to  the  computer  system  that  a  partic¬ 
ular  operation  should  be  performed.  A  variable  function  key 
may  perform  different  functions,  depending  on  what  kind  of 
activity  the  user/operator  is  performing.  Usually  the  specific 
effect  of  pressing  a  given  variable  function  key  is  indicated 
by  a  brief  menu  presented  on  the  terminal  or  on  transparent 
key  label  overlays  or  underlays. 


KEY  1;  STORE  KEY  2:  RETRIEVE  KEY  3:  EDIT 
KEY  k:  XMIT  KEY  5:  VIEW  QUEUE 
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Light  pen  dialog,  which  is  usually  a  special  form  of  menu 
dialog  in  which  the  user/operator  touches  a  light  pen  to  the 
option  that  identifies  the  command  which  the  user/operator 
desires. 


THE  AVAILABLE  OPTIONS  AAE 


□  RETRIEVE  OATA 

□  STORE  OATA 

□  EDIT  OATA 

□  A00  A  FILE 

□  DELETE 


Cursor  control  dialog,  which  i3  usually  a  special  form  of 
menu  dialog,  in  which  the  user/operator  positions  the  screen 
cursor  next  to  the  desired  command.  The  cursor  may  be  moved 
with  any  graphic  positioning  device.  In  the  example  below, 
the  user/operator  is  using  a  joystick. 


THE  AVAIUBIE  OPTIONS  AK£ 


□  RETRIEVE  DATA 

□  STORE  DATA 

□  EDIT  OATA 

□  A00  A  FILE 
^  DELETE  A  FILE 


User-initiated  command  language  dialog,  in  which  the  user./ 
operator  enters  commands  in  response  to  a  prompt  symbol 
appearing  on  the  terminal.  The  prompt  is  typically  brief, 
so  the  user/operator  must  remember  the  command  codes  and 
options  and  accuratel  •  type  them  at  the  terminal. 


COWIANO?  FILEiWRHG.OATi  /LJ/FHT3 


Natural  language  dialog,  which  typically  is  user -initiated 
command  language,  in  which  the  designer  attempts  to  make 
the  command  language  as  much  like  standard  English  as  pos- 


Voice  input,  which  is  typically  a  form  of  user-initiated 
command  language,  where  the  user/operator  speaks  commands 
instead  of  typing  them. 
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1.1.5  RECOMMENDATIONS  FOR  ALPHANUMERIC  CONTROL  METHODS  . 

Selection  of  the  dialog  type  depends  on  the  nature  of  the  system  being 
developed  and  the  characteristics  of  the  expected  users/operators  of  the  sys¬ 
tem.  Some  of  the  most  important  factors  in  making  this  decision  are : 

a.  Sophistication  of  the  users/operators. 


1.  HIGH  level  of  sophistication  means  that  users/operators 
are  very  familiar  with  the  system,  its  capabilities,  and 
the  sequences  of  operations  which  the  system  will  perform. 
Users/operators  with  a  HIGH  level  of  sophistication  will 
have  (a)  received  a  substantial  amount  of  training  in  sys¬ 
tem  operation  or  (b)  had  considerable  experience  in  operat¬ 
ing  the  system  by  the  time  they  are  called  on  to  use  it  in 
operational  situations,  or  (c)  both  of  the  above. 

2.  MEDIUM  level  of  sophistication  means  that  users/operators 
are  quite  familiar  with  the  most  important  capabilities 
and  commands  of  the  system,  but  are  not  intimately 
familiar  with  little-used  system  features.  Users/operators 
with  a  MEDIUM  level  of  sophistication  may  have  received 
considerable  training,  but  will  not  have  used  the  system 
enough  to  maintain  their  knowledge  about  all  of  the  sys¬ 
tem's  capabilities. 

3.  LOW  level  of  sophistication  means  that  users/operators  are 
familiar  only  with  the  "big  picture"  of  system  operation. 
They  may  be  unfamiliar  with  the  range  of  capabilities  of 
the  system. 

4.  VARIABLE  level  of  sophistication  means  that  different  users/ 
operators  have  different  levels  of  sophistication  in  using 
the  system.  Some  may  be  very  familiar  with  its  features 
and  capabilities,  while  others  will  be  aware  of  only  the 
most  elementary  or  important  features. 

b.  Number  of  commands 


1.  VERY  HIGH — more  than  300  separate  commands  and  command 
options. 

2.  HIGH— 151  to  300  separate  commands  and  command  options. 

3.  MEDIUM — 51  to  150  separate  commands  and  command  options. 

4.  LOW — 50  or  fewer  separate  commands  and  command  options. 

c.  Number  of  times  an  average  command  will  be  used  by  a  typical 
user/operator  in  a  given  period  of  time. 

1.  HIGH — average  command  used  5  times  per  day  or  more. 
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2.  MEDIUM — average  command  used  twice  per  week  or  more  but 
less  than  5  times  per  day. 

3.  LOW — average  command  used  less  than  twice  per  week, 
d.  computer-to-terminal  data  transmission  rate. 


1.  HIGH — 4800  baud  (480  characters  per  second)  or  greater. 

2.  MEDIUM — 1200  baud  (120  characters  per  second)  or  greater, 
but  less  than  4800  baud  (480  characters  per  second) . 

3.  LOW — less  than  1200  baud  (120  characters  per  second). 

Table  1.1-1,  Dialc _  I’ype  by  System  and  System  user  Characteristics,  pre 
sents  a  general  list  of  io commendations  for  selecting  dialog  types.  Before 
making  a  final  decision  on  dialog  type,  be  sure  to  consult  the  advisory  com¬ 
ments  for  individual  dialog  types  presented  in  the  next  section  (Section 
1.1.6,  Advisory  Comments  for  Alphanumeric  Contract  Methods). 

To  use  the  table,  first  decide  what  system  and  system  user  characteris¬ 
tics  apply  to  the  situation  you  are  considering.  Eliminate  any  dialog  types 
where  a  "4"  appears  as  an  entry.  Select  the  best  dialog  type  by  comparing 
the  remaining  types  in  view  of  the  type  of  system  you  are  conceptualizing  or 
designing. 


Table  1.1-1.  Dialog  Type  by  System  and  System  User  Characteristics 


!  •  RECtmNOEO 
Z  -  ACCEPTABLE 

3  -  WORKABLE  BUT  SUBORTIHAL 

4  •  NOT  REC0WENDED  OR  NOT  APPLICABLE 


GlItST I0W  AK0  ANSWER  DIALOG 


TOR*  FILLING 


F|*C0  FUNCTION  KITS 


VARIABLE  FUNCTION  KITS 


H|NU  SELECTION 


LIGHT  PIN  DIALOG 


CURSOR  CONTROL  DIALOG 


USER-INITIATED  CO*VA0  LANGUAGE 


NATURAL  LANGUAGE  DIALOG 


VOICE  INPUT 


CHARACTERISTIC  OF  SVSTEH  0»  STSTEM  USIS 
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1.1.6  ADVISORY  COMMENTS  FOR  ALPHANUMERIC  CONTROL  METHODS 

a.  Question  and  answer  dialog 

1.  Use  question  and  answer  dialogs  only  when  the  users/operators 
are  likely  to  be  very  unsophisticated  in  using  system  capa¬ 
bilities. 

2.  Use  question  and  answer  dialog  when  the  users/operators  ara 
required  to  provide  only  "YES”  or  "NO"  answers  to  questions 
generated  by  the  computer  systems. 

3.  Use  question  and  answer  dialogs  when  the  user /operator  is 
required  to  enter  information  which  cannot  be  placed  on  a 
list  or  easily  encoded  (e.g.,  time  other  than  current  time; 
number  of  troops) . 

4.  When  using  question  and  answer  dialogs,  provide  examples 
of  required  command  format  and  content  whenever  possible. 

b.  Form  filling 


1.  Use  form  filling  when  the  user/operator  is  typing  in  commands 
which  have  been  written  or  typed  previously  on  a  hard  copy 
form. 

2.  When  using  form  filling,  provide  a  convenient  means  to  con¬ 
trol  cursor  movement  from  f ield-to-f ield  as  well  as  from  line- 
to-line  and  character  position-to-character  position. 

3.  when  the  user/operator  is  using  form  filling  to  enter  com¬ 
mands  written  or  typed  on  hard  copy,  make  the  image  of  the 
form  displayed  on  the  CRT  screen  look  as  much  like  the  hard 
copy  form  as  possible. 

4.  Avoid  using  form  filling  whan  the  system  must  handle  multi¬ 
ple  form  tyixsa  and  the  computer-to-terminal  data  transmission 
rate  is  low.  In  this  situation,  it  will  take  too  long  to 
display  the  different  forms  when  the  user/oporator  oust 
shift  from  form-to-form. 

c.  Fixed  function  keys 


„T‘ 


1.  Use  accurately  labeled  fixed  function  keys  when  users/opora- 
tors  are  likely  to  be  very  unsophisticated  in  the  use  of 
computer  systems  and  the  command  set  is  small. 

2.  Croup  fixed  function  keys  by  purpose,  type  of  data  involved, 
etc. 

3.  I?  fixed  function  keys  are  enabled  only  at  certain  joints 
during  system  operations,  and  arc  disabled  at  other  times, 
provide  a  light  behind  each  key  which  is  ON  w5w>n  the  key 
is  enabled. 


1.1-11 


:  •*  V- 
V-.V.'S  .5 


1.1.6 


fi 


i 


■>>: 

<4 

rS>: 


1 


d.  Variable  function  keys 

1.  When  a  constant  set  of  commands  is  available  at  all  points 

in  system  operation,  place  these  commands  on  the  same  variable 
function  keys  throughout  system  operation.  Note?  from  the 
standpoint  of  the  user,  these  becare  fixed  function  keys. 

2.  As  much  as  possible,  place  command  labels  on,  in,  or  beside 
variable  function  keys  rather  than  listing  options  in  menu 
form  on  the  display  and  numerically  or  alphanumerically 
encoding  the  function  keys. 

3.  Where  long-term  usage  of  a  particular  variable  function  key 
configuration  is  likely,  provide  key  caps  or  other  labeling 
overlays/underlays  to  differentiate  variable  function  keys. 

4.  where  different  users/operators  use  the  same  terminal  and 
system  for  different  purposes,  provide  each  user/operator 
with  a  set  of  overlays/underlays  to  designate  the  commands 
associated  with  particular  variable  function  keys  for  each 
particular  application. 
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e.  Menu  selection 


1.  Use  menu  dialogs  when  the  command  set  is  so  large  that  users/ 
operators  are  not  likely  to  be  able  to  commit  all  camnands 

to  memory. 

2.  Where  there  are  logical  relationships  among  ccmmands,  pre¬ 
sent  groups  of  menus  in  a  sequence  which  is  in  accordance 
with  those  logical  relationships.  For  example,  where  com¬ 
mands  are  hierarchical,  arrange  the  menus  in  a  sequence  from 
general  to  specific  command  formulation. 


Use  menu  dialogs  where  at  least  some  of  the  users/oporators 
may  not  be  familiar  with  all  of  the  functions  of  the  system. 

Where  there  is  a  wide  difference  in  five  sophistication  of  the 
set  of  expected  usors/gperators,  present  menus  of  different 
levels  of  detail. 

Whore  some  of  the  users/operators  are,  or  will  become,  very 
sophisticated  in  system  operation,  provide  a  method  for  by¬ 
passing  menu  displays  by  stacking  commands,  i.e.,  entering 
whole  set  of  comaands  in  anticipation  of  upcoming  dis¬ 
plays.  Ttiis  recommends t ion  is  particularly  important  where 
the  d#-ta  transmission  rate  available  will  require  that  the 
time  to  display  the  menu  will  exceed  two  seconds.  (See 
Figure  1.1-1.) 


Pso  a  light  pen  dialog  in  systems  where  the  users/operaters 
are  likely  to  be  unfamiliar  with  '  he  commands  and  functions 
of  the  system. 
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CHARACTERS 
IN  MENU 


KEY 


•  NO  CQtHUiO  STACK  NECESSARY 

•  CdtMWD  STACK  NECESSARY  FOR  HICKEY  SOPHISTICATED  USER 

•  Ca»VWO  STACK  NECESSARY  FOR  NODE  SATE  SOPHISTICATED  USER 

•  CO* two  STACK  NECESSARY  FOR  UNSOPHISTICATED  USER 

•  USE  Of  MENUS  NOT  RECOMMENDED 


ri^tjre  Sequirosicnts  for  COvSt*an4  Stack  Given  Various  Cwsfaina 

tio.Ys  of  Characters  in  :<enus  and  Data  Transmission 
Rates. 
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2.  When  using  a  light  pen  dialog,  make  certain  that  the  "targets" 
for  the  light  pen  are  at  least  1/4"  square. 

3.  If  the  user/operator  is  to  use  the  light  pen  for  more  than 
1/4  hour  continuously,  place  the  display  screen  in  a  hori¬ 
zontal  or  nearly  horizontal  position  so  that  the  user/opera¬ 
tor  does  not  tire. 

4.  If  the  user/operator  must  make  light  pen  transactions  more 
frequently  than  one  every  five  minutes,  place  the  display 
screen  in  a  horizontal  or  nearly  horizontal  position  so 
that  the  user/operator  does  not  tire. 

5.  Avoid  using  light  pen  dialogs  where  the  users/operators  of 
the  system  will  be  highly  sophisticated  in  system  functions 
and  operations. 


Cursor  control  dialog 


1.  Use  a  cursor  control  dialog  when  conceptualizing  or  design¬ 
ing  systems  which  have  interactive  graphics  as  their  primary 
purpose,  but  which  must  use  alphanumeric  menu  presentation 
in  some  processing  steps. 


2.  Avoid  using  a  cursor  control  dialog  when  the  users/operators 
of  the  system  will  have  no  need  to  control  the  position  of 
the  cursor  on  the  CRT  screen  other  than  to  select  items  frcm 
an  alphanumeric  command  menu  or  list. 


3.  Use  the  same  method  for  the  cursor  control  dialog  as  is  used 
for  graphics  interaction. 

4.  When  using  a  cursor  control  dialog,  make  the  "target"  for  the 
cursor  at  least  10  times  the  size  of  the  positioning  accuracy 
required  for  interactive  graphics  or  1/4"  square,  whichever 
is  smaller. 

5.  Provide  feedback  to  the  user /operator  on  which  "target"  has 
been  selected  by  the  cursor  control  dialogs.  Making  the 
selected  target  brighter  is  the  preferred  method.  (See 
Section  2.3,  Selective  Highlighting.) 

User-initiated  command  language 

1.  Use  user-initiated  command  language  when  sophisticated  users 
are  working  with  a  system  having  a  large  number  of  capabili¬ 
ties  . 


Before  committing  to  command  language  dialog,  be  sure  to 
check  the  implications  of  command  language  code  structure 
and  syntax  presented  in  the  discussion  of  alphanumeric  for¬ 
mats  for  message  composition  aids  presented  in  Section  4.1. 
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Natural  lang 


1.  Use  natural  language  dialog  where  unsophisticated  users/ 
operators  must  use  a  system  with  a  moderate  number  of  com¬ 
mands  . 

2.  Use  natural  language  dialogs  when  the  set  of  commands  can 
be  made  to  reflect  usage  of  common  English  language  terms. 

3.  Where  some  sophisticated  users  will  use  a  system  with  nat¬ 
ural  language  dialog,  provide  for  command  codes  and  abbre¬ 
viations  as  an  option  to  natural  language  interaction. 

Voice  Input 

1.  Use  voice  inputs  where  the  user's/operator's  hands  and  eyes 
are  already  being  used  extensively  in  other  system  operations 
For  example,  voice  inputs  might  be  useful  in  an  interactive 
graphics  system. 

2.  Limit  the  use  of  voice  input  to  situations  where  the  ambient 
noise  level  is  less  than  90  dBA. 
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1.2.2  APPLICATIONS  FOR  GRAPHICS  CONTROL  METHODS 


a.  Selecting  or  specifying  graphics  commands.  In  this  application, 
the  user  or  operator  indicates  to  the  computer  system  what  graphics 
functions  he/she  wishes  to  perform.  Graphics  functions  include: 
adding  symbols  to  the  display,  moving  symbols  on  the  display, 
deleting  symbols  from  the  display,  etc. 

EXAMPLE:  In  an  artillery  fire  control  system,  the  CRT  display 
shows  the  position  of  targets  by  "overlaying"  them  on  a  map  of 
the  battlefield  area.  The  user/operator  has  received  informa¬ 
tion  that  one  of  the  targets  has  been  destroyed,  so  he/she  wishes 
to  delete  the  symbol  which  depicts  that  target.  Tc  do  this,  the 
user/operator  presses  a  fixed  function  key  marked  "SYMBOL  DELETE," 
touches  a  light  pen  to  the  symbol  to  be  deleted,  and  presses  the 
"execute"  button  on  the  light  pen. 
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Sketching  or  drawing  linos  on  the  display.  The  user  or  operator 
uses  a  graphics  control  device  to  sketch  lines  on  the  display. 

In  many  ways,  this  is  similar  to  using  a  piece  of  chalk  to  draw 
on  a  blackboard. 

EXAMPLE:  In  a  command  and  control  system,  the  operator  of  a 
battalion-level  component  of  the  system  can  send  graphics  displays 
to  division  and  higher  echelons.  The  division  commander  requests 
information  on  the  routes  which  enemy  forces  are  expected  to  take 
to  engage  the  battalion.  The.  battalion  commander  has  the  system 
operator  call  up  a  display  of  the  battlefield  area.  He/she  then 
uses  a  light  pen  to  sketch  the  most  probable  routes  of  the  enemy's 
advance.  The  operator  sends  the  altered  display  to  the  division- 
level  component  of  the  system. 
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Following  detailed  lines  from  hard  coi 


Placing  and  moving  symbols  on  the  display.  In  many  types  of 
graphics  displays,  the  user  or  operator  is  required  to  alter 
the  display  by  placing  new  symbols  on  it,  moving  existing 
symbols,  or  deleting  existing  symbols. 

EXAMPLE:  In  a  command  and  control  system,  the  user /opera tor 
receives  messages  from  field  commanders  describing  in  general 
the  position  of  the  Army  units  which  he  cctnmands.  Exact  coor 
dinates  are  not  given.  The  user/operator  interprets  these 
messages,  retrieves  a  digital  version  of  a  chart  which  cor¬ 
responds  to  the  position  of  the  units,  and  moves  the  units  to 
a  new  chart  position  using  a  trackball. 
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e.  Selecting  display  parameters.  In  some  graphics  applications, 
the  user/operator  will  decide  that  only  a  certain  class  ot' 
symbols  be  presented  on  a  display.  The  user /operator  must 
therefore  have  the  capability  to  indicate  what  information 
he/she  wishes  to  be  displayed. 

EXAMPLE:  In  a  logistics/supply  system,  the  user  wishes  to 
review  the  history  of  stocks  of  equipment,  types.  The  user 
enters  the  equipment  type  code,  and  the  system  displays  the 
percentage  of  authorized  stock  levels  over  the  last  12  months. 


EQUIPMENT 

A.  BEARING,  ROLLER.  1/2  INCH  (AM2/DQ-1009127) 

B.  BEARING,  ROLLER,  3/8  INCH  (AI1Z/DZ-2189323) 

C.  BEARING,  ROLLER,  1/*  INCH  (AMZ/DX-3179432) 
0.  BEARING,  SLEEVE,  1/2  INCH  (AMX.OB-l 0739921) 


ENTER  DESIRED  EQUIPMENT  TYPE  ~>  B 
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Orienting  symbols.  In  sane  graphics  systems,  the  orientation  (or 
direction  of  pointing)  of  symbols  may  be  important,  regardless  of 
the  position  of  the  symbol  on  the  display.  The  user  or  operator 
must  have  the  capability  for  specifying  this  orientation. 

EXAMPIE:  An  artillery  unit  has  shifted  its  firing  orientation 
from  85°  to  47°.  The  user  of  an  artillery  fire  planning  system 
wishes  to  change  the  indicated  orientation  of  that  unit  so 
that  displays  including  the  artillery  unit  show  the  current 
orientation.  The  user  changes  the  value  for  orientation  of  the 
artillery  unit  by  entering  a  cctnmand  which  changes  the  orienta¬ 
tion  value  from  85°  to  47°. 
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1.2.3  BENEFITS  FOR  GRAPHICS  CONTROL  METHODS 


Graphics  control  methods  should  enable  users/operators  to  quickly  and 
easily  specify  and/or  modify  the  contents  of  the  displays  which  they  are 
using.  Appropriate  selection  of  graphics  control  methods  can  have  the  follow 
ing  benefits: 

a.  Reduced  time  to  alter  the  displays  to  conform  to  the  require¬ 
ments  of  a  particular  battlefield  situation. 

b.  Reduced  errors  in  selecting  symbols  or  specifying  the  kinds  of 
symbols  which  are  to  be  included  in  the  display. 

c.  Reduced  operator  fatigue,  which  could  result  from  using  graphics 
control  methods  which  are  ill-suited  to  the  physical  and/or  behav¬ 
ioral  characteristics  of  the  users/operators. 
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THOOS  FOR  GRAPHICS  CONTROL  METHODS 

Alphanumeric  interaction  dialog.  The  appearance,  placement, 
and  movement  of  graphics  symbols  on  a  display  can  be  controlled 
by  the  types  of  alphanumeric  dialog  discussed  in  Section  1.1, 
Alphanumeric  Control  Methods. 


UHAT  SYMBOL  DO  YOU  WISH  fO  DISPLAY?  -  HVY  AAA 
THE  OEFAULT  SYMBOL  IS: 

00  YOU  WISH  TO  CHANGE  THE  SYMBOL?  -  NO 


ENTER  GRID  COORDINATES  FOR  SYMBOL: 
VERTICAL  -  13/ 

HORIZONTAL  —  209 


00  YOU  HtSH  TO  CHANGE  THE  SUE  Of  THE  SYMBOL?  -  KO 
DO  YOU  MtSH  TO  ROTATE  THE  SYMBOL?  -  MO 
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e.  Joystick.  The  user/operator  moves  a  vertical  lever  or  "stick" 
which  is  implanted  in  the  top  surface  of  the  keyboard  panel 
(or  in  a  separate  joystick  case) .  Most  joysticks  are  mechani¬ 
cally  configured.  They  resemble  a  rod  stuck  into  a  ball  which 
has  been  bored  in  the  top  of  the  keyboard  cover,  and  they  move 
smoothly  throughout  the  cone  of  rotation. 


1.  Direct  positioning  joystick.  With  this  type  of  joystick, 
the  cursor  moves  in  the  direction  of  the  movement  of  the 
joystick.  The  speed  of  cursor  movement  is  determined  by 
the  speed  with  which  the  joystick  is  moved.  The  distance 
to  which  the  cursor  moves  is  dependent  upon  the  extent 
of  displacement  of  the  cursor,  i.e.,  the  angle  of  the 
cursor  relative  to  the  plate  in  which  it  rests. 


SCREEN  CURSOR  CENTERED 
ON  THE  DISPLAY  SCREEN 


JOYSTICK  DISPLACED  ALL 
THE  WAY  AWAY  FROM 
THE  USER/OPERATOR 


SCREEN  CURSOR  AT  CENTER  OF 
TOP  OF  DISPLAY  SCREEN 


JOYSTICK  DISPLACED  HALFWAY 
TOWARD  THE  LIMIT  OF  ITS 
DISPLACEMENT  IN  THE  "4:30 
O'CLOCK"  DIRECTION  (135”) 


SCREEN  CURSOR  POSITIONED 
HALFWAY  TO  EDGE  OF  DISPLAY 
SCREEN  IN  THE  “4:30  O'CLOCK" 
DIRECTION  (135*; 
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2.  Relative  positioning  joystick.  In  this  configuration,  the 
cursor  also  moves  in  the  direction  of  the  movement  of  the 
joystick.  But,  the  speed  of  cursor  movement  is  dependent 
upon  the  extent  of  displacement  of  the  joystick  (i.e.,  its 
angle  relative  to  the  plate)  rather  than  joystick  movement 
and  the  cursor  continues  to  move  across  the  screen  in  the 
given  direction  as  long  as  the  joystick  is  displaced. 

Thus,  in  i  his  instance,  the  distance  the  cursor  moves  is 
dependent  upon  the  combination  of  time  and  extent  of  joy¬ 
stick  displacement. 


JOYSTICK  IN  TOP 
CENTER  POSITION 


SCREEN  CURSOR  IN 
CENTER  OF  SCREEN, 
NOT  MOVING 


Stow  CURSOR  MOVEMENT 


JOYSTICK  DISPLACED  HALFWAY 
TOWARD  6  O'CLOCK  POSITION 
(180”) 


AFTER  1  SECOND 

SCREEN  CURSOR  AT  6  O'CLOCK 
FROM  SCREEN  CENTER,  1/8  OF 
THE  WAY  TOWARD  THE  EDGE 


AFTER  2  SECONDS 

SCREEN  CURSOR  AT  6  O'CLOCK 
FROM  SCREEN  CENTER.  2/8  OF 
THE  WAY  TOWARD  THE  EDGE 


AFTER  3  SECONDS 

SCREEN  CURSOR  AT  6  O'CLOCK 
FROM  SCREEN  CENTER,  3/8  OF 
THE  WAY  TOWARD  THE  EDGE 


fast  cursor  movement 


AFTER  1  8ECOND 


JOYSTICK  DISPLACED  FULLY 
TOHARD  6  O'CLOCK  DESTINA¬ 
TION  (180-) 


l 


SCREEN  CURSOR  AT  6  O'CLOCK 
FROM  SCREEN  CENTER.  1/4  OF 
THE  HAY  TOWARD  THE  EDGE 


AFTER  2  SECONDS 

SCREEN  CURSOR  AT  6  O'CLOCK 
FROM  SCREEN  CENTER,  2/4  OF 
THE  HAY  TOWARD  THE  EDGE 


AFTER  3  8ECONDS 

SCREEN  CURSOR  AT  6  O'CLOCK 
FROM  SCREEN  CENTER.  3/4  OF 
THE  HAY  TOHARD  THE  EDGE 
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3.  Stepping  or  detent  joystick.  Displacement  of  the  joystick 
from  its  top  dead  center  position  results  in  a  constant 
rate  of  motion  of  the  screen  cursor  until  a  particular 
angular  rate  of  displacement  is  reached.  In  the  second 
zone,  the  screen  cursor  moves  faster  than  in  the  first; 
in  the  third  zone  faster  yet,  etc.  Usually,  moving  from 
one  zone  to  a  faster  one  requires  an  increase  in  force  on 
the  joystick  lever.  This  assures  that  the  user/operator 
will  know  that  the  rate  of  cursor  movement  is  changing. 
There  are  ordinarily  three  "zones"  in  this  type  of  joy¬ 
stick  implementation. 


■ZONE  3:  1.0  IN/SEC 
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Piezoelectric  or  strain  gauge  joystick.  In  this  configura¬ 
tion  the  joystick  lever  is  not  movable.  The  direction  of 
movement  of  the  screen  cursor  is  determined  by  the  direction 
of  the  pressure  on  the  lever.  The  speed  of  movement  is 
determined  by  the  amount  of  pressure  applied. 


3  oz.  FORCE  DIRECTED 
AT  1:30  O'CLOCK  (45*) 


SCREEN  CURSOR  MOVES 
AT  45”  TOWARD  EDGE 
OF  SCREEN  AT  .5  IN./ 
SEC. 


SCREEN  CURSOR  MOVES 
AT  180”  TOWARD  EDGE 
OF  SCREEN  AT  2.0  IN./ 
SEC. 


NOTE:  Both  stepping  and  piezoelectric  joysticks  are 

implemented  only  as  relative  positioning  graphics 
interaction  devices. 
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Digitizing  pad/tablet.  The  user/operator  places  a  digitizing 
device  on  the  surface  of  a  position-sensing  grid.  The  positions 
on  the  grid  are  directly  related  to  the  positions  on  the  display 
screen.  By  placing  the  digitizing  device  at  a  particular  point 
on  the  grid,  the  user/operator  can  cause  the  screen  cursor  to 
move  to  the  analogous  position.  The  digitizing  device  may  be 
a  stylus. 


iSi 


I _ _ 

In  ■■■■■■■■■■■■■■■■■■■■  ■■■■IS 

|BBBBBBBBBBBIBBflBBBBBBBF3BBBBi| 
IBBBflBBBBBBBBaBBBBBBBaBbaBBBBk: 
|BBBBaBaaBaBBBBBBBaBBB*BBaB:4BB 

Ibbbbbbbbbbbbbbbbbbbbqbbbbbbbb 

|aaaaBa|aBBPaBa*sa*BBaaaByaBBa 

iBBBBBBBBaBimanBBBavaBBB^aaflBa 
lgBBBBaai££fcX¥i£BaaUBBB’2BBBBB4 
liaBBBBpBBBaKCNBiiaaB«B9BBBaBaB 
I  ■BBBBBBBBPKBfl  JII*3tJBBDUBBBBBSBB 

|BBBBBBBBBBBBBBBBBBBBB2'BBIflBBBB 

|BBBBBBBBBBBBBBBBBBBBBBBBBBBBB 


Or,  the  device  may  be  a  cross-hair  digitizing  cursor 


IlBaaaaBBBBBBaflBBaaaaBBBBaaaBBa 
laaaaaaaaaBlaaaaBaaBBaaaaaaaaa 
laaaaaBBaBaBBBaaaBaaaaenaaBifVN 

b!bb!bSb!S5!5b!b!S!!S5Sbb!5bb 

Bk^sbbbb 

_ _ HinBiBaBaa 

I^^^^^^^^^maaaaBBa*BBBBaj 
_ _ ___BBbbbbbbbbbsbbbbI 

bbbbbbbbbbbbbbbbbbbbijBbbbbbbb 

BaaBBBaBBaaaaaaaBaBBKiaaMaaaaa 

■BBaiaaBBaBBaaaaaaBBaaBiiBaBMa 

aBBaBaBBBaaaaaaaiBBaaaaaaaBnia 

aaaaaBiBiBBaaaaBiaMaaaaaaaaa 

■  BBBBBiBBBBBaaaBBr/<*'«£fMiB4'ia 

■aaaa!BaBaaaaBaaaLV:4.fTk\maBB 
BBBBBiBflBBiBBBBBBB>AV^\V^B 
aiBBBBBBBfliBaBBBBB^^DblBllIl^ 
BiBaa8aaBBaaBaBaBam2«MMjd 

s:;SsssS£:SS;i::;;:j|MW 
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2  presses 

3  presses 


Or,  the  screen  cursor  may  continue  to  move  as  long  as  the  key  is 
being  pressed. 
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Keyboard  coordinate  entry.  The  user/operator  types  in  the 
coordinates  of  the  item/phenomenon  with  which  he/she  wishes 
to  work. 


ENTER  COORDINATES  OF  ITEM  OF  INTEREST  IN  UTM  OR 
LAT/LON  ~> 


Scanner /digitizer .  In  this  type  of  interaction,  the  user/opera¬ 
tor  works  with  a  digitizing  pad,  tablet,  or  table  which  is  linked 
to  a  "flying  spot  scanner"  (FSS) .  The  FSS  is  registered  to  the 
same  hard  copy  which  is  placed  on  the  digitizing  hardware.  The 
scanner  tracks  the  placement  of  the  digitizing  device,  reducing 
the  requirement  for  the  user /operator  to  follow  a  line  precisely. 


Touch  sensitive  pad.  The  user/operator  controls  the  movement 
of  the  screen  cursor  by  moving  a  finger  across  the  surface  of 
a  small,  touch  sensitive  surface.  The  direction  of  movement 
of  the  screen  cursor  is  controlled  by  the  orientation  of  the 
finger  with  respect  to  the  center  of  the  touch  sensitive  sur¬ 
face.  The  speed  of  movement  of  the  screen  cursor  is  determined 
by  the  distance  of  the  finger  from  the  center  of  the  surface. 


Selecting  or  specifying  graphics  commands.  The  appropriateness 
of  particular  graphics  control  methods  for  selecting  or  specify¬ 
ing  graphics  commands  depends  on  at  least  the  following  factors: 

1.  The  number  of  commands  which  are  available  for  use  by  the 
user  or  operator.  Some  methods  are  very  convenient  when 
there  are  only  a  few  commands  required,  but  become  unwieldy 
when  there  are  large  numbers  of  commands. 

2.  The  availability  of  multiple  screen  displays,  which  can 
determine  whether  presentation  of  graphics  command  options 
will  require  that  the  "working"  graphics  display  be  replaced 
by  a  listing  of  the  available  command  options. 

3.  The  rate  at  which  commands  will  be  used  in  a  typical  applica¬ 
tion. 

4.  The  complexity  of  commands,  in  terms  of  whether  only  the 
command  is  required,  or  whether  a  parameter  or  set  of  para¬ 
meters  must  accompany  the  command. 

Recommendations  for  using  graphics  control  methods  for  selecting 
or  specifying  graphics  commands  are  presented  in  Table  1.2-2. 


Table  1.2-2.  General  Recommendations  for  Graphics  Control 
Methods  for  Selecting  and  Specifying  Graphic 
Commands 
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c.  Tracing  detailed  lines  or  points  from  hard  copy.  Selection 
of  the  best  graphics  control  method  for  tracing  detailed  lines 
or  points  from  hard  copy  materials  requires  consideration  of 
the  following  factors: 

1.  The  line/symbol  placement  accuracy  required  in  the  partic¬ 
ular  application. 

2.  The  amount  of  clutter  on  the  hard  copy,  i.e.,  the  relative 
amount  of  undesired  lines  and  symbols  on  the  hard  copy  as 
compared  to  the  number  or  amount  of  desired  lines  or  sym¬ 
bols. 

3.  The  type  of  digitization  required.  In  general,  stream 
digitization  will  be  used  when  the  user  wishes  to  trace 
the  route  of  some  item  from  the  hard  copy  display,  e.g., 
river,  road,  railroad,  political  boundary.  Point  digi¬ 
tization  will  be  used  to  indicate  the  position  of  figures 
and  symbols  on  the  hard  copy. 

Recommendations  for  using  graphics  control  methods  for  tracing 
detailed  lines  or  points  from  hard  copy  are  presented  in  Table 
1.2-4. 


Table  1.2-4.  Recommendations  for  Using  Graphics  Control  Methods 
for  Tracing  Detailed  Lines  or  Points  from  Hard  Copy 
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d.  Placing,  moving,  indicating,  and  deleting  symbols.  The  considera¬ 
tions  involved  in  placing,  moving,  indicating,  and  deleting  sym¬ 
bols  on  a  graphics  display  include: 

1.  Line/symbol  placement  accuracy  requirements  of  the  particular 
application. 

2 .  The  required  speed  for  symbol  manipulation. 

3.  The  rationale  for  symbol  placement,  i.e.,  whether  the 
final  location  of  the  symbol  to  be  placed  or  moved  is 
at  the  discretion  of  the  user  or  operator,  or  whether 
its  location  has  been  or  can  be  specified  by  the  use 
of  georeference  coordinates. 

Recommendations  for  using  graphics  control  methods  for  placing, 
moving,  indicating,  and  deleting  symbols  are  presented  in  Table 
1.2-5. 


Table  1.2-5.  Recommendations  for  Graphics  Control  Methods  for 
Placing,  Moving,  Indicating,  and  Deleting  Symbols 
from  a  Graphics  Display 
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Selecting  display  parameters.  Selection  of  the  best  graphics 
control  method  for  selecting  display  parameters  involves  con¬ 
sideration  of  at  least  the  following  factors: 


1.  The  number  of  parameters  which  are  available. 


2 .  The  availability  of  multiple-screen  displays. 


3 .  The  rate  at  which  parameters  are  to  be  selected. 


Recommendations  for  using  graphics  control  methods  for  selecting 
display  parameters  are  presented  in  Table  1.2-6. 


Table  1.2-6.  Recommendations  for  Graphics  Control  Methods 
for  Selecting  Display  Parameters 


1.3.1  DEFINITION 

HELP  features  are  those  which  assist  the  user  in  determining  what  the 
system  is  capable  of  doing,  or  what  user  actions  and  inputs  are  required  to 
perform  a  desired  function,  or  the  meaning  of  displays  and  messages  produced 
by  the  system. 
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1.3.2  APPLICATIONS  FOR  HELP  FEATURES 


M 


E 

I 
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HELP  features  can  be  used  to  assist  users/operators  in  virtually  all 
aspects  of  computer  system  operation.  Some  of  the  more  important  applications 
of  HELP  features  include: 

a .  Assistance  in  controlling  the  operations  of  the  system.  Here , 

HELP  features  may  be  used  to: 

1.  Inform  users/operators  about  the  capabilities  of  the  system, 
in  terms  of  what  the  system  can  and  cannot  do. 

2.  Indicate  to  users/operators  what  commands  or  actions  are 
required  to  cause  the  system  to  perform  a  desired  operation. 

3.  Indicate  the  correct  format  for  commands. 

4.  Indicate  what  options  are  available  for  specific  commands, 
and  how  the  user  is  to  select  those  options. 

b.  Assistance  in  interpreting  the  output  of  the  system,  by  helping 

to: 

1.  Explain  to  the  user  the  format  and  content  of  displays  used 
in  the  system  outputs. 

2.  Explain  abbreviations  and  contractions  used  in  the  displays 
to  conserve  valuable  display  space. 

3.  Indicate  the  circumstances  under  which  particular  displays 
or  portions  of  displays  will  be  produced  by  the  system. 


f  < 


c.  Assistance  in  entry  of  data  into  the  system,  by  helping  to: 

1.  Indicate  to  the  user  the  correct  form  and  content  of  infor¬ 
mation  to  be  entered  into  the  system. 

2.  Indicate  to  the  user  options  in  the  way  information  can  or 
should  be  entered  into  the  system. 

3.  Explain  the  methods  for  getting  information  into  the  sys¬ 
tem,  and  under  what  circumstances  these  methods  should  be 
used. 

4.  Provide  lists  of  legal  terms  to  be  used  in  data  entry. 

5.  Provide  indications  of  the  legal  values  associated  with 
particular  data  items. 

d.  Assistance  in  querying  data  bases,  by  helping  to: 


1.  Explain  the  kinds  of  guories  which  can  be  performed  on  the 
data  base. 


1.3.2 


2.  Explain  the  proper  format  for  queries  to  be  entered  in  the 
system. 

3.  Indicate  how  options  in  data  base  query  are  to  be  formed 
and  entered  into  the  system. 

4.  Explain  how  to  store,  retrieve,  and  modify  standing  or 
stored  queries  to  avoid  reentering  complex  data  retrieval 
requests. 
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e.  Assistance  in  message  generation,  by  helping  to: 

1.  Indicate  what  kinds  of  messages  may  be  created  using  the 
system. 

2.  Explain  the  way  in  which  messages  are  created. 

3.  Explain  the  meaning  of  specific  commands  used  in  the 
creation  of  messages. 

4.  Explain  procedures  for  avoiding  unnecessary  system  inter¬ 
action  when  filling  out  sparsely  filled  messages. 


f.  Assistance  in  error  handling,  by  helping  to: 

1.  Explain  the  conditions  under  which  errors  will  be  de¬ 
tected  and  those  under  which  errors  will  not  be  detected. 

2.  Indicate  the  kinds  of  error  detection  performed  by  the 
system. 

3-  Provide  detailed  information  on  the  meaning  of  error  mes¬ 
sages  generated  by  the  system. 

4.  Suggest  in  detail  the  potential  causes  of  errors  about 
which  the  user  has  been  notified. 

5.  Explain  procedures  used  to  correct  errors. 
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1.3.3  BENEFITS  OF  HELP  FEATURES 


Use  of  appropriate  HELP  features  will  make  it  easier  for  system  users, 
particularly  inexperienced  ones,  to  determine  how  to  use  the  system  to  best 

advantage.  Good  HELP  feature  design  will  enhance  overall  system  performance 
by: 

a-  Reducing  error  rates,  by  minimizing: 

1.  Errors  due  to  the  lack  of  specific  information  on  particular 
commands,  data  entry  strings,  etc. 

2.  Errors  resulting  from  a  lack  of  convenient  methods  for  check¬ 
ing  the  legality  of  command,  data,  and  query  inputs. 

b.  Increasing  system  throughput  rates,  by  minimizing: 

1*  Time  required  to  locate  information  dealing  with  a  partic¬ 
ular  aspect  of  system  operation. 

2.  Time  required  to  hunt  through  irrelevant  guidance  to  locate 
desired  assistance  information. 

3.  Time  spent  in  consulting  with  more  experienced  users 
because  appropriate  assistance  information  was  not  avail¬ 
able  on-line. 

4.  Time  required  to  locate  paper  reference  material  which  may 
have  been  mislaid  or  damaged. 
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1.3.4  METHODS  FOR  IMPLEMENTING  HELP  FEATURES 

The  implementation  of  HELP  features  involves  consideration  of  at  least 
six  aspects  of  HELP  methods.  These  are:  the  method  for  accessing  the  HELP 
feature;  the  effect  of  accessing  the  HELP  feature;  the  structure  of  the  HELP 
files  or  information  provided  to  the  user;  the  way  in  which  HELP  information 
is  presented  to  the  user;  the  specificity  of  HELP  information  presented  to 
the  user;  and  the  nature  of  transfer  of  control  or  data  entry  information 
from  the  HELP  feature  to  system  operation  or  control.  These  six  issues  are 
discussed  in  more  detail  below. 

a.  Method  for  accessing  HELP.  There  are  several  methods  commonly 
employed  to  permit  the  system  user  to  indicate  that  he/she  wishes 
to  review  HELP  information.  These  include: 

1.  HELP  key.  Here,  the  user  presses  a  key  marked  HELP  to  indi¬ 
cate  a  desire  to  review  HELP  information.  The  key  may  be  a 
fixed  function  key  or  a  programmable  function  key. 

2.  HELP  symbol.  Here,  the  user  enters  a  symbol  to  indicate  a 
desire  to  receive  HELP  information.  The  most  commonly  used 
symbol  is  a  question  mark  (?). 

3.  HELP  command  string.  In  this  method  the  user  types  in  a 
command  to  indicate  a  desire  to  review  HELP  information. 

The  most  commonly  used  string  is  "HELP." 


Reference  to  a  manual  or  other  hard  copy  job  aid.  Here, 
the  user  has  no  access  to  on-line  HELP  information,  or  the 
information  which  is  provided  is  so  sketchy  that  it  must 
be  supplemented  via  a  paper  document.  In  this  method,  the 
user  is  provided  with  what  is  essentially  a  user's  manual, 
although  it  may  be  structured  so  as  to  provide  a  more  con¬ 
venient  reference  in  those  situations  when  HELP  information 
would  ordinarily  be  requested  from  the  system. 


b.  Effect  of  accessing  HELP  information.  The  issue  here  is  what 
happens  when  the  user  requests  access  to  HELP  information. 
There  are  several  methods  of  dealing  with  user  requests  for 
HELP  information,  including: 


1.  Single-thread  or  unitary  HELP,  in  which  the  user  or  opera¬ 
tor  receives  the  same  information  no  matter  under  what 
conditions  the  HELP  information  is  requested.  For 
example,  if  a  system  employs  a  KELP  key,  the  same  KKIi* 
information  would  be  presented  to  the  user  nn  matter 
what  system-related  operations  were  being  performed  when 
the  key  was  pressed. 
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2.  Situation-dependent  HELP.  In  this  method,  the  system  would 
vary  its  presentation  of  HELP  information  depending  on  the 
kind  of  activity  being  performed  when  the  HELP  feature  was 
engaged.  For  example,  if  the  user  were  in  the  process  of 
performing  a  query,  the  system  would  respond  with  informa¬ 
tion  about  performing  a  query.  If  the  user  were  faced  with 
a  prompt  requesting  a  command,  the  system  would  respond 
with  information  about  the  available  commands  or  with 
information  about  the  format  of  the  commands  which  were 
legal  at  that  point  in  system  processing. 

3.  User-selectable  situation  dependence  for  HELP  feature.  Here, 
the  user  specifies  whether  the  HELP  information  to  be  pre¬ 
sented  should  be  situation-dependent  or  not. 

4.  Menu-selectable  HELP  subfunction.  In  this  method,  request¬ 
ing  the  HELP  function  results  in  the  display  of  a  HELP  menu, 
from  which  the  user  may  request  the  specific  information 
which  he/she  desires.  In  general,  the  menu  is  tailored  to 
the  specific  process  which  the  user  is  performing,  but  menu 
options  to  access  HELP  information  unrelated  to  that  pro¬ 
cess  are  also  provided. 

c.  HELP  information  structure.  Methods  here  deal  with  how  the  HELP 

information  to  be  provided  to  the  user  is  organized.  Options 

in  HELP  information  structure  include: 

1.  Linear  HELP  structure,  in  which  all  of  the  information  on 
a  given  topic  is  presented  in  sequential,  linear  fashion, 
much  as  it  might  be  in  a  chapter  of  a  book  or  users’  manual. 

2 •  Hierarchical  HELP  structure,  in  which  the  HELP  information 
is  configured  in  a  hierarchical  set,  so  that  users  can 
iteratively  specify  in  increasing  detail  their  specific 
HELP  information  needs.  The  structure  may  be  either  situa¬ 
tion-dependent  or  situation-independent. 

3-  Multi-level  hierarchical  HELP  structure.  In  this  method 
the  entry  points  in  the  hierarchy  are  at  various  levels, 
rather  than  being  only  at  the  top  of  the  hierarchy.  In 
other  words,  the  HELP  system  structure  attempts  to  esti¬ 
mate  the  level  of  detail  of  information  needed  by  the  user 
on  the  basis  of  what  activities  arc  being  performed,  and 
to  provide  the  user  with  information  at  appropriate  levels 
of  informational  specificity. 

4.  Kcference  to  HSU*  manual.  In  this  method,  the  only  practical 
way  of  obtaining  information  about  system  capabilities  is 
to  look  it  up  in  a  hard-copy  reference  manual,  the  on¬ 
line  HELP  capability  is  nonexistent  or  extremely  limited. 

d.  HELP  data  presentation.  There  are  at  least  five  methods  for 

presenting  HELP  information  to  the  user: 
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Replace  current  display,  in  which  the  HELP  information 
either  "overwrites"  the  working  display  or  is  tacked  onto 
the  end  of  the  current  display.  This  method  of  presenting 
RELP  information  can /  and  usually  does*  destroy  at  least 
part  of  the  display  on  which  the  user  was  working  before 
HELP  was  requested. 

2*  Reserved  HELP  screen  area,  in  which  HELP  messages  appear  in 
an  area  of  the  screen  which  is  set  aside  for  HELP  informa¬ 
tion  only.  This  screen  area  will  therefore  be  blank  unless 
HELP  data  has  been  requested.  This  method  has  the  disadvan¬ 
tage  of  reducing  the  amount  of  screen  space  for  both  the 
HELP  information  and  other  information  which  is  to  be  dis¬ 
played  on  the  screen. 

3*  Separate  HELP  display  screen.  In  this  method,  the  HELP 
information  is  displayed  on  a  screen  completely  separate 
from  the  one  which  contains  the  displays  with  which  the 
user  is  working  when  the  HELP  data  are  requested.  Generally, 
the  two  screens  are  placed  in  close  proximity  to  each  other 
to  increase  the  ease  with  which  HELP  information  may  be  com¬ 
pared  to  the  contents  of  the  working  display. 

4’  Hard  copy  of  HELP  displays,  m  this  method,  HELP  information, 
whether  it  is  currently  being  displayed  on  the  CRT  or  has  been 
requested,  may  be  printed  out  at  a  hard-copy  station. 

5*  HELP  manuals.  Here,  the  HELP  information  available  to  the 
user  has  been  previously  extracted  from  the  system,  organized 
in  some  fashion,  and  placed  into  a  HELP  manual.  The  user 
nust  decide,  assisted  by  the  structure  of  and  any  index (es) 
to  the  manual,  what  portions  of  the  manual  to  reference  to 
obtain  the  required  data. 

.HRRP  information  specificity.  Different  users,  as  well  as  dif¬ 
ferent  operating  conditions  and  situations,  may  require  different 
levels  of  spocificity  in  the  amount  of  information  presented  to 
the  user  when  a  HELP  information  is  presented.  Three  methods 
for  dealing  with  the  specificity  of  HELP  information  are: 

^ •  Ringle-spocif icity  HELP,  in  which  the  information  contained 
in  response  to  a  request  for  HELP  information  is  always  at 
the  same  level  of  specificity. 

2-  Variable,  user-selectable  HELP  specificity,  in  which  the 
HELP  feature  includes  two  or  more  levels  of  specificity  of 
information  which  may  be  displayed  to  the  user.  For  example, 
in  a  ground  order-of-battlo  system,  the  user  may  be  inter¬ 
ested  in  knowing  what  the  code  "TR7a"  moans.  If  the  “brief" 
or  “concise"  HELP  mode  has  been  selected,  tho  following  HELP 
message  might  be  provided: 


T8?a - SOV.  MAIN  BTTL.  TNK. 


If  the  "full"  or  "complete"  mode  were  selected,  the  HELP 
message  would  be  considerably  more  detailed,  and  might 
appear  like  the  following: 

"T87a— -SOVIET  MAIN  BATTLE  TANK.  STANDARD 
EQUIPMENT:  133  MM  GUN;  34  RNDS.  HEAT;  15  RNDS. 

HE;  5  RNDS.  SMOKE;  LASER  RANGEFINDER;  RADAR 
DETECTOR  FOR  X-BAND;  SNORKEL  (12  FT.  STREAM 
TRAVERSE) .  OPTIONAL  EQUIPMENT:  TUBE  FIRED 
'TALON  IV'  LWIR  SEEKER  MISSILE  {12  KM.  RANGE); 

•RAZOR'  RPV  RECON  (LWIR,  VISUAL,  ACOUSTIC, 

MAGNETIC  DETECTION.)" 

3.  Pointers  to  HELP  manual  sections:  In  this  method,  the  HELP 
information  display  either  consists  of  or  includes  a  refer¬ 
ence  to  the  user  or  HELP  manual  section  in  which  the  user 
can  find  more  information  on  the  issue  of  interest.  Such 
pointers  may  cither  replace  or  supplement  existing  HELP 
messages  provided  on-line. 

HELP  information  transfer.  Once  the  user/operator  has  located 
the  desired  information  in  a  HELP  display,  there  remains  the 
problem  of  how  to  use  that  information  in  performing  the 
activity  about  which  the  user  had  questions  in  the  first  place. 
There  are  at  least  three  methods  of  transferring  the  informa¬ 
tion  back  to  the  data  or  command  entry  display  from  which  the 
HELP  display  was  called: 

1.  Return  only.  In  this  method,  the  user  reviews  the  HELP 
information  and  then  commands  the  system  to  return  to 
operational,  rattier  than  HELP,  mode.  The  user  must 
remember  the  HELP  information  (or  obtain  a  hard  copy  of 
it  for  reference)  in  order  to  use  it  appropriately. 

2.  Single-parameter  HELP.  In  this  method,  the  user  may 
select  while  in  HEW  mode  an  option  from  a  menu  list, 

or  may  formulate  a  command  based  on  the  information  con¬ 
tained  in  thu  HELP  display.  This  information  is  then 
automatically  passed  back  to  the  operational  program, 
where  it  is  treated  exactly  as  though  the  user  had  entered 
the  command  in  response  to  the  command  or  data  entry  prompt 
in  the  operational  program. 

3.  HEW  command  construction  capability.  This  mode  is  similar 
to  the  "mo  discussed  just  previously,  except  that  the  user 
has  the  option  to  select  a  whole  series  of  commands  or  data 
entries  while  viewing  the  HELP  information.  This  n  .thod 
permits  the  user  to  address  complex  command  or  data  entry 
issues  while  reviewing  the  HELP  files  themselves,  rather 
than  trying  to  remember  command/data  entry  formats  and 
contents  after  having  returned  to  an  operational  display. 
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1,3.5  RECOMMENDATIONS  FOR  HELP  FUNCTIONS 

Selection  of  HELP  function  methods  depends  on  the  nature  of  the  system 
being  developed  and  the  characteristics  of  the  ussrs/operators  of  the  system. 
Some  of  the  most  important  factors  involved  in  making  these  decisions  include 

a.  Sophistication  and  experience  of  the  users/operators. 

1.  HIGH  level  of  sophistication  means  that  the  users/operators 
are  very  familiar  with  the  system,  its  capabilities,  and  the 
types  and  sequences  of  operations  and  data  entries  with  which 
the  system  will  deal.  Users/operators  with  a  HIGH  level  of 
sophistication  will  have  (a)  received  a  substantial  amount 

of  training  in  system  operation  and  data  entry  or  (b)  had 
considerable  experience  in  operating  the  system  by  the  time 
they  are  called  upon  to  use  it  in  operational  situations, 
or  (c)  both  of  the  above. 

2.  MEDIUM  level  of  sophistication  means  that  users/operators 
are  quite  familiar  with  most  of  the  important  capabilities, 
commands,  data  entries,  display  formats,  etc.,  associated 
with  system  operation,  but  are  not  intimately  familiar  with 
little-used  features  of  the  system.  Users/operators  with  a 
MEDIUM  level  of  sophistication  may  have  received  consider¬ 
able  training,  but  will  not  have  used  the  system  enough  to 
maintain  their  knowledge  about  all  of  the  capabilities  of 
the  system. 

3.  LOW  level  of  sophistication  means  that  users/operators  are 
familiar  with  only  the  “big  picture"  of  system  operation. 

They  may  bG  familiar  with  some  of  its  features  and  capa¬ 
bilities,  but  not  all  or  even  the  most  important  ones. 

4.  VARIABLE  level  of  sophistication  means  that  different  users/ 
operators  have  different  levels  of  experience  and  capability 
in  using  the  system.  Some. may  be  very  familiar  with  its 
features  and  capabilities,  while  others  will  be  aware  of 
only  the  most  elementary  or  important  features. 

b.  Number  of  commands . 

1.  MIGW--fflore  ehan  600  separate  commands,  command  options, 
data  entry  elements,  and  query  items. 

2.  MEDIUM — '201  to  600  separate  commands.  command  options, 
data  entry  types,  and  query  items. 

3.  L0« — S  to  200  separate  commands,  command  options,  data 
entry  types ,  and  query  items. 

c.  Cocsputer-to-tertsinal  data  transmission  rate. 

1.  HIGH — 4800  baud  (480  characters  per  second)  or  greater. 
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2.  MEDIUM — 1200  baud  (120  characters  per  second)  or  greater,  but 
less  than  4800  baud  (480  characters  per  second) . 

3.  LOW — less  than  i200  baud  (120  characters  per  second). 

d.  Complexity  of  system. 

1.  HIGH — more  than  50  separate  functions  perfc.rmable  by  the 
system,  wit.;  numerous  subfunctions  associated  with  each 
function. 

?..  MEDIUM — 11  to  50  separate  functions  performable  using 
the  system,  with  numerous  subfunctions  associated  with 
each  function. 

3.  LOW — 10  or  fewer  separate  functions  perform/ ble  using 
the  system. 

e.  Storage  available 

1.  HIGH — there  is  sufficient  storaqe  to  provide  high-speed 
access  on-line  to  essentially  .  )  1  .information  which  even 
the  most  unsophisticated  user  w.uld  need  to  perform 
required  interactive  operations  using  the  system. 

2.  LOW — there  is  insufficient  storage  to  provide  full  HELP 
information  on-line. 

Recommendations  for  the  use  of  specific  HELP  functions  methods  are 
presented  in  Table  1.3-1. 
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Table  1.3-1.  Recommendations  for  the  Use  of  Specific  HELP  Functions  and 
Methods 


DECISION  FACTOR 


KEY : 

1  -  RE CORNER 0£ A 

2  -  ACCEPTABLE 

3  -  WORKABLE  BUT  K'JB OPTIMA! 


EXPERIENCE 

OF 

USERS 


DATA 

TRANSFER 

RATE 


NtfSER  OF 
COfKANDS/ 
DATA  INPUTS 


COMPLEXITY 

OF 

SYSTEM 


STORAGE 

AVAR'IB.E 


1.3.6  ADVISORY  COMMENTS  FOR  HELP  FUNCTIONS 


a.  Method  for  accessing  HELP 

1.  If  use  of  a  HELP  symbol  is  contemplated,  the  question  mark 
is  the  preferred  symbol. 

2.  If  use  of  a  HELP  command  string  is  contemplated,  the  word 
"HELP"  is  the  preferred  command. 

3.  Always  provide  the  user/operator  with  a  user's  manual  or  other 
reference  manual  which  essentially  duplicates  the  contents 

of  on-line  HELP  information,  even  if  complete  HELP  information 
is  provided  on-line. 

4.  Provide  an  exhaustive  index  to  all  hard-copy  HELP  information. 

5.  Always  provide  a  method  for  obtaining  assistance  on  specific 
commands,  data  entry  items,  query  items,  etc.  This  method 
should  be  implemented  as  follows: 

(a)  HELP  key — (command  or  other  item  for  which  HELP  is 
desired)  +  (press  HELP  KEY)  =  desired  HELP  display. 

(b)  HELP  character —  (command  or  other  item  for  which 
HELP  is  desired)  +  (HELP  symbol)  =*  desired  HELP 
display. 

(c)  HELP  string-- (HELP  string)  +  (command  or  other 
item  for  which  HELP  is  desired)  =  desired  HELP  dis¬ 
play. 

6.  If  system  users  have  had  extensive  training  or  experience  in 
the  use  of  other  systems  which  use  a  particular  method  for 
accessing  HELP,  provide  that  method  in  addition  to  the  one 
most  appropriate  for  the  system  being  designed  or  modified. 

7.  Affix  a  printed  label  or  sign  to  the  terminal  indicating 
to  the  user  how  to  obtain  HELP  and  use  the  HELP  functions 
of  the  system. 

b.  Effect  of  accessing  HELP 


1.  Use  single-thread  HELP  with  systems  which  are  so  simple  that 
all  of  the  information  which  a  user  might  need  to  know  about 
the  system  can  be  placed  on  a  single  display. 

2.  Provide  a  method  for  overriding  automatic  situation-dependent 
selection  of  HELP  displays. 

3.  When  a  situation-dependent  HELP  display  feature  is  being  used, 
always  provide  a  method  for  the  user  to  escape  from  the  HELP 
display  which  is  presented  and  to  access  information  about 
system  functions  other  than  the  one  which  is  being  used  cur¬ 
rently. 
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c.  HELP  information  structure 


Use  a  linear  HELP  structure  only  when  the  system  is  so  simple 
that  the  information  required  to  HELP  the  user  through  any  con¬ 
ceivable  situation  can  be  presented  in  four  or  fewer  HELP  dis¬ 
plays. 

d.  HELP  data  presentation 

1.  When  using  current  display  replacement,  arrange  for  display 
of  HELP  information  such  that  as  little  of  the  workina  dis¬ 
play  is  erased  as  possible.  That  is,  do  not  gratuitously 
erase  the  entire  contents  of  a  working  display  simply  to 
present  a  four-line  HELP  message. 

2 .  When  using  a  reserved  area  for  HELP  displays ,  provide  a 
capability  to  (a)  replace  the  working  display  with  more 
detailed  HELP  information,  (b)  produce  a  hard  copy  of  the 
more  detailed  information,  or  (c)  reference  pages  in  a 
paper  reference  manual  which  provide  the  more  detailed  HELP 
information,  or  (d)  use  some  combination  of  the  above. 

3.  When  using  current  display  replacement,  returning  from  the 
HELP  display  to  the  operational  display  should  present  the 
user  with  exactly  the  same  situation  as  existed  prior  to 
requesting  the  HELP  information — except  in  the  case  where 
responses  to  the  working  display  can  be  entered  while 
viewing  the  HELP  display.  In  the  first  instance,  the 
response  must  still  be  entered;  in  the  second  instance, 

it  has  already  been  entered. 

e.  HELP  information  specificity 
No  advisory  comments. 

f.  HELP  information  transfer 


No  advisory  comments. 
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DISPLAY  TECHNIQUES 


Guidelines  in  this  category  specify  methods  for  information  presentation 
which  contribute  to  user/operator  accuracy  and  efficiency  in  information  pre¬ 
sentation  and  utilization.  Speed,  ease,  and  accuracy  of  comprehension  are 
important  factors  here.  Display  techniques  are  considered  within  the  follow¬ 
ing  three  categories: 

1.  Alphanumeric  Displays  describes  conditions  and  techniques 
appropriate  to  generation  of  displays  for  alphanumeric  data 
presentation. 

2.  Graphics  Displays  describes  conditions  under  which  pictorial 
and  diagrammatic  presentation  of  information  are  appropriate 
and  delineate  techniques  for  achieving  optimum  presentation. 

3.  Selective  Highlighting  describes  techniques  for  differentiating 
displayed  items  which  are  of  special  interest  to  the  user/ 
operator  from  those  which  are  more  routine. 

Some  display  formats  are  better  suited  to  specific  use  conditions  than  others. 
Table  2-1  summarizes  some  of  these  use  and  display  format  relationships. 

Table  2-1.  Display  Techniques  by  Application 


KEY : 

1  -  APPROPRIATE 

2  -  ACCEPTABLE 

3  -  INAPPROPRIATE 


DISPLAY 

TECHNIQUE 

APPLICATION 

Fixed  or 
Free 
Text 
Report 

Statis¬ 

tical 

Report 

Trend 

Data 

Pictorial, 

Symoolic 

Presen¬ 

tation 

HELPS 

Error 

Messages 

Alphanumeric 

1 

1 

4 

4 

1 

l 

Graphic 

4 

2 

1 

1 

2 

4 

2.1.1  DEFINITION 


2.1  Alphanumeric  Displays 
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Alphanumeric  displays  are  screen  or  hard-copy  presentations  of  information 
composed  of  the  alphanumeric  symbol  sets.  (See  the  discussion  of  symbols  and 
symbol  sets  in  Section  6.1.)  To  the  extent  that  grammatical  symbols  are 
required  for  textual  separation,  or  that  special  symbols  associated  with  a 
specific  area  of  science  or  technology  are  required,  fixed  alphanumeric  dis¬ 
plays  also  contain  these  additional  symbols  and  symbol  sets. 
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2.1.2  APPLICATIONS  FOR  ALPHANUMERIC  DISPLAYS 

Alphanumeric  displays  are  appropriate  for: 

a.  Presentation  of  layouts  for  data  entry. 

EXAMPLE:  In  a  field  artillery  system,  all  information  is 
entered  within  a  selected  prestructured  message  format. 

The  format  consists  of  data  field  labels,  data  field 
delimiters  (made  up  of  grammatical  symbols) ,  and  spaces 
for  data  element  entry.  All  entries  are  alphanumeric 
codes.  Data  entry  length  can  not  exceed  the  space  allowed, 
and  only  proper  information  (legal  entries)  can  be  entered 
within  a  given  data  field. 

b.  Display  of  data  for  information  or  action  purposes. 

EXAMPLE:  A  user/operator  calls  up  a  report  on  the  number 
and  status  of  heavy  tanks  for  an  armored  division  of  a 
potential  aggressor.  After  reviewing  the  report,  the  user/ 
operator  cancels  the  display. 

EXAMPLE:  In  a  field  medical  unit,  the  user/operator  calls 
up  the  most  recent  medical  supplies  requisition.  Due  to 
recent  unexpected  adverse  battle  outcomes,  the  user/operator 
modifies  the  requisition  to  reflect  medical  supply  needs  for 
dealing  with  casualties  and  the  report  status  is  changed 
from  "routine*'  to  "emergency." 

c.  Display  of  a  list  of  performance  or  other  options  (menu) . 

EXAMPLE:  A  tactical  intelligence  data  handling  system  functions, 
in  part,  through  user/operator  call-up  of  preformatted  displays 
and,  in  part,  through  the  use  of  menus.  Once  the  user/operator 
logs  onto  the  system,  a  list  of  the  machine's  functions — a 
master  menu — is  automatically  presented  on  the  screen.  Selec¬ 
tion  of  a  function  from  the  master  menu  results,  in  some 
instances,  in  presentation  of  preformatted  displays  through 
which  the  user/operator  constructs  command  statements  to  per¬ 
form  functions  available  in  that  mode  of  operation. 

d.  Presentation  of  HELPs  to  aid  the  usor/operator . 

EXAMPLE:  One  of  the  master  menu  options  in  the  preceding 
example  is  a  "HELP"  option.  Selection  of  the  HELP  option 
brings  up  the  HELP  display  which  provides  brief  definitions 
and  descriptions  of  the  coded  options  listed  on  the  master 
menu. 

g .  Presentation  of  error  feedback  and  error  correction  informa- 
tion. 
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2.1.3  BENEFITS  OF  ALPHANUMERIC  DISPLAYS 

Proper  utilization  of  alphanumeric  displays  will  enhance  overall  system 
performance  through  improved  user/operator  performance  by: 


a.  Reducing  error  rates,  by  minimizing: 

1.  The  necessity  for  recalling  information  from  memory  due 
to  insufficient  display  of  essential  information. 

2.  Suboptimum  display  formats  which  make  discriminations 
between  separate  items  of  information  difficult. 

3.  Improper  retrieval  of  essential  information  due  to 
inappropriate  mode  and/or  features  of  information 
presentation. 

4.  Difficulty  in  distinguishing  among  logical  subelements 
of  a  data  item  which  is  required  for  subsequent  com¬ 
mand  or  data  item  entry. 

b.  Increasing  system  throughput  rates,  by  minimizing: 

1.  Difficulty  in  locating  information  displayed  on  the 
screen. 

2.  Time  required  to  identify  and  correct  errors. 

3.  Efficiency  of  the  data  organization  for  data  entry  and 
retrieval . 

4.  Requirement  to  postpone  operation  due  to  delay  in 
obtaining  requisite  information. 
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2.1.4  METHODS  FOR  ALPHANUMERIC  01 SPLAYS 

Alphanumeric  displays  are  of  two  basic  types:  fixed  and  variable 

a.  Fixed  alphanumeric  displays.  Fixed  alphanumeric  displays  can 
not  be  varied  by  the  user/operator  in  shape,  size,  or  data 
element  label.  Fixed  alphanumeric  displays  can  be  provided 
through  the  following  methods: 

1.  Lists  of  appropriate  information.  These  lists  can  take 
any  of  a  variety  of  forms. 

(a)  Lists  may  be  in  the  form  of  legal  codes  as  follows, 
for  example,  for  ammunition  type: 


AMMUNITION  TYPE 


NUMBER  CODE  LETTER  CODE 


Armor  piercing 

1 

ARM 

Biological 

2 

BIO 

Fragmentation 

3 

fra 

Gas/Chemical 

4 

GAS 

Illumination  (Flare) 

5 

ILL 

Incendiary 

6 

INC 

Nuclear 

7 

NUC 

Smoke 

8 

SMO 

(b)  Lists  may  be  in  the  form  of 

code  definitions 

,  as 

follows,  for  ammunition  type  codes: 

LETTER  CODE  NUMBER  CODE  AMMUNITION 

TYRE 

Armor  piercing 

Biological 

Fragmentation 

Gas/Chomieal 

Illumination  (Flare) 

Incendiary 

Nuclear 


(c)  Lists  may  be  in  the  form  of  a  menu  which  presents 
options,  as  shown  below  for  selection  of  ammunition 


types: 

- ^ 

I  AVAILABLE  AMMUNITION  TYPES  ARE:  I 


1. 

ARM  — 

ARMOR  PIERCING 

2. 

BIO  — 

BIOLOGICAL 

3. 

FRA  — 

FRAGMENTATION 

4. 

GAS  — 

GAS/CHEMICAL 

5. 

ILL  — 

ILLUMINATION  (FLARE) 

6. 

INC  — 

INCENDIARY 

7. 

NUC  — 

NUCLEAR 

8. 

SMO  — 

SMOKE 

ENTER  THE  #  OS  LETTER  COOE  FOR  DESIRED  AMMUNITION  TYPE,  OR  ENTER 
ONLY  A  CARRIAGE  RETURN  TO  GET  BACi.  — » 
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Prestructured  formats. 

(a)  Prestructured  formats  are  used  for  "registered"  entry 
of  data,  ft  prestructured  format  for  data  entry  is 
made  up  of  a  data  field  label  and  space  for  data  ele¬ 
ment  entry.  Those  formats  are  a  version  of  "fill-in- 
the-blanks"  which  basically  look  like; 

WSTR:  )  AZ:  _ ;  DF :  _ i 

F2: _ / _ ; 

or : 

S : _ /  #  /  ,/,/  ,/  ,/ 

Usually,  a  variety  of  information  types  is  required  to 
complete  a  prostructured  format.  For  esutnple,  the  PLOT 
CONTROL  DATA  format  shown  below  requires  identifier  data 
(PLOT  tOi,  scry  NARK:,  TITLE: 5.  addressee  data  (NAME  OF 
FILE  TO  RECEIVE  THIS  DATA;),  as  well  as  detailed  param¬ 
eters  of  the  plot  (LOWER  LEFT  GEO:,  PROJECTION:, 
SPHEROID:  ,  STANDARD  PARALLELS :  •  LAT  INC:.  LONG  INC: , 
etc. ) . 


PLOT  CONTROL  DATA 

NAME  OF  FILE  TO  RECEIVE  THIS  DATA: 

PLOT  10:  5CTY  HARK:  ~  ~  TlTlt:' 


LOWER  LEFT  GEO: 

PROJECTION:  IpHEROTO:  ~ 

STANDARD  PARALLELS :_  _ 

LAT  INC.:  CoSG_ISC.  :~ 


UPPER  RIGHT  GEO: 

HAP  SCALE: _ '  RAF  ME?:-  _  " 

REF.  LONG:  “  GRID  TYPE:  ' 

UTH  INC.:-  ~  " 


KARGINS:  TOP: _ BOTTOM: _  LEFT: _ RIGHT: _ 

LETTER  SCALE:  SYWOL  SCALE :  PLOT  COLOR:  PRIORITY: 

RESOLUTION^  ~  ”  _  ~  OVERWRITE:,  “ 

HEASUREHENT  OVERRIDE: 

LOWER  LEFt:  X:_  _  Y:  UT:_  _  LONG:_  _ 

UPPER  RIGHT:  X:  ~  ~  Y:  LAT:  LONG: 


J 

As  in  the  previous  examples  (for  FZ:  and  FZES:),  the  number 
of  alphanumeric  characters  which  may  be  entered  is  limited 
to  the  number  of  blanks  following  the  data  field  label: 

PROJECTION: _  SPHEROID: 

Different  conditions  can  be  imposed  with  respect  to  the 
requirement  for  filling  in  the  blanks  following  the  data 
field  label.  Under  some  circumstances  (as  determined  dur¬ 
ing  system  design)  there  may  be  a  requirement  to  fill  in 
all  the  blanks.  Or,  some  systems  may  permit  codes  of 
varied  length  for  a  given  data  field,  thereby  sometimes 
permitting  the  nonuse  of  alpivanumeric  cliaracter  blanks. 

Prestructured  formats  can  also  vary  the  requirement  for  use 
or  nonuse,  i.e.,  the  conditions  of  use  of  a  complete  data 
field,  as  follows: 

(R)  Required  entry. 

(I»)  Entry  of  one  or  more  of  a  multiple  set 
of  fields. 

(C)  Conditional  entry — completion  of  one  data 
element  requires  completion  of  another. 

(O)  Optional  entry. 

(til  Do  NOT  enter  data. 

(A)  or  (»)  Entry  of  at  least  one  set  of  data 
required  in  a  multiple  Set  field. 

The  twg  following  formats  demonstrate  use  of  the  above 
conditional  data  entry  requirements.  Those  codes- -shown 
shaded  in  the  f orstats--are  not  part  of  the  data  entry. 

The  codes  can  be  3?rescnted  off-line  in  documentation 
Or,  if  presented  on-line,  they  are  overridden  by  data 
entry  or  otherwise  deleted  so  that  they  do  not  inter¬ 
fere  with  data  entered  into  the  format. 
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Prestructured  formats  are  also  used  for  alphanumeric 
data  output .  In  this  usage  they  are  standard  reports 
whose  basic  structure  does  not  alter  no  matter  what 
the  extent  of  data  available  or  requested.  They  are 
formulated  on  the  basis  of  information  already  avail¬ 
able  in  the  "machine."  Prestructured  formats  can  be 
very  small  or  very  lengthy,  as  shown  below.  In  some 
instances  they  produce  multiple  pages  and/or  multiple 
screens  of  output. 


ACK  2  ;P:2;SB:F/S/0/2  /B0E;C:UK  ;S6:  7,  7 tDT:09,l 7/51/02 ; ID:  491 A 
FH:NT0:T6T:AFOO20;KNPT:  ;AUG:  till  ;V0L:  6-.UNITS:  3;FPF:  ; 
SHAJ:  ;FZP:  ;SHEF :HEA2/HEA1 ;FZ : PDA  /PDA  ;HE:  ;  ; 

CONY.-ffi  /FF£  ;T0F:27  SiAAGUT:  ;PER:  ;M'$:  J 


A  TACFTRE  fire  mission  (FM)  output  message  to  observer 
(MTO)  generated  by  the  request  for  additional  fire 
(FMsRFAF;  input  message. 


FH;5201;  :ETO 

FH  RECOMMENDATION 
TGT:AY0213;FR0N:A/C/C/  / 


;DTG:**/  0/20; 


F  ;P:2;S8:A/C/C/  /  ;C:ETO;SG:  1,  2;DT:00.00/20/24;ID:  41  ;A:  ; 
FM;RFAF:  tMYEFF:  ;TGT:AY0213;C0RD:  43400/  34500/  310;GZ:  ; 

SPHERE;  ;DIR:  /  ;TYPE:  /  ;DOP:  -.SIZE:  /  ; 

AH:  iSTR:  ;RV:  ;SH;  /  ;FZ:  /  ;DTG:  /  /  ;TOT:  /  ; 

UFFES:  /  //  /  ;///  /  ,///  /  .///  /  ,////; 
CONT:  /  ;EFF:  ;V0t:  ;EOH:  ;0PT:  ;H1S:  ;PRI;  jATII:  ; 

OB:  ;DD:  /  .  ;PTM:  d 

ATI  BATA: 

TGT : 0T701 2 ;CORO : 549500/  3834600/  360;GZ:  14;SPHERE:1; 

TYPE:WPN  /HVMG  ;DOP:  ;SIZE:  15/  ;ATT:  ; 

STR:  2;RV:  5;VEGTAT:  ;PERHNC:  ;HASKTI:15S; CLOTHE:  ; 

0TG:29/  3/46;PT: 


MISSION  DATA: 

T GT . AY 02 13; CORD : 54 9400/  3834500/  310;GZ:  14;$PHERE:1; 

TTPEiPERS  /tJNK  ;DOP:PRUG  ;SIZE:  100/  ;ATT: 
STR:  ;PV:100;VEGTAT:  ;PERHNC:  ;MASKTI : 

ZONES: 50IV  ;2NB0E  ,121NF  , 

DISTANCE  BETWEEN  MISSION  AND  ATI  TGT  141  HETERS 
NUK3ER  OF  TGTS  WITHIN  1  KM  3 

TGT:AY02)3;  IN  FCA:BENNIE;COORDINATE  WITH  FC0RD:FS02DBDE  ; 
FU:  /  /C/1  /41  iTGTBEYOND  MAX  RANGE 
TGT:AY0213;0UT  OF  TRANVERSE  OF  FU:  /  /C/5  /16  ; 
TGT:AY0213;ASSIGNED  BY  ATI 

TGTAY021 3 ;TYPt/SUBTYPE  OF  PERSONNEL/UNKNOWN  ASSUMED 


RQDR  EFF:15;ACTUAl  EFF:15;  RQRD  VOL:  -.ACTUAL  VOL: 


FU  SHELL 

/  /C/5  /1 6  HEC3/HFC3 

/  /A/5  /1 6  HEC3/HEC3 

/  /B/5  /1 6  HEC3/HEC3 

8N  FIRING  ALONE  EFF  VOL  RD 
5  /16  15  32 


FUZE 

TIC  /TIC 
TIC  /TIC 
TIC  /TIC 


EFFALONE 

7 

9 

9 


3N  FIRING  TOGETHER  EFF  VOL  RD 


A  TACFIRE  output  message  generated  by  the  fire  mission 
request  for  additional  fire  (FMiRFAF)  input  message 
which  provides  artillery  target  intelligence  and  mis¬ 
sion  data. 
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3.  HELPS.  HELPS  are  another  form  of  fixed  alphanumeric  dis¬ 
plays.  The  command  method  utilized  affects  the  format  of 
the  HELP. 

4.  Error  messages.  Error  messages  provided  through  the  system 
are  yet  another  form  of  fixed  alphanumeric  displays. 

Variable  alphanumeric  displays.  The  essential  characteristic 
of  variable  alphanumeric  displays  which  distinguishes  them 
from  fixed  alphanumeric  displays  is  that  their  construction 
and  content  are  under  user/operator  control.  Variable  alpha¬ 
numeric  displays  are  provided  through  methods  comparable  to 
fixed  displays,  i.e.,  through  lists  or  display  formats.  Lacking 
any  rigid  structure  into  which  information  must  be  formatted, 
variable  alphanumeric  displays  are  most  useful  for  generation 
of: 

1.  Free  text  reports  when  the  substence  and  structure  of  the 
report  are  up  to  the  generating  user/operator . 

2.  Shoe  box  files  or  personal  files  through  which  the  user/ 
operator  generates  HELPS,  interim  sets  of  data,  or  any 
set  of  personally  useful  operational  information. 
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2.1.5  RECOMMENDATIONS  FOR  ALPHANUMERIC  DISPLAYS 

a.  Table  2.1-1/  Method  of  Alphanumeric  Display  by  Application, 
presents  general  recommendations  for  the  use  of  particular 
displays  according  to  the  type  of  output  required  by  the 
user /operator . 

b.  Use  alphanumeric  displays  to  present  alphanumeric  informa¬ 
tion  by  which  the  user/operator  can  control  the  system. 

c.  use  alphanumeric  displays  to  allow  the  user/operator  to 
interact  with  the  system  on  a  non-pro  forma  basis,  i.e., 
for  the  generation  of  user/operator-unique  working  files, 
frequently  referred  to  as  "shoe  box  files." 

d.  Use  alphanumeric  displays  to  permit  user/operator  genera¬ 
tion  of  standard  and  nonstandard  output  reports  in  both 
textual  and  tabular  formats. 

e.  Allow  the  user /operator  to  use  alphanumeric  displays  to 
tag  and/or  annotate  graphics  displays. 


Table  2.1-1.  Method  of  Alphanumeric  Display  by  Application 


KEY: 

APPLICATION 

1  -  RECOMMENDED 

2  -  ACCEPTABLE 

3  -  WORKABLE  8UT  $U80PT!MAL 

4  -  NOT  RECOMMENDED  OR  NOT 

APPLICABLE 

LAYOUTS  FOR  OATA 

ENTRY 

OATA  DISPLAY  FOR  IN¬ 
FORMATION  OR  ACTION 

DISPLAY  OF  PERFOR¬ 
MANCE  OPTIONS 

[  PRESENTATION  OF 

HELPS 

1  PRESENTATION  OF  ERROR 
j  INFORMATION 

Q 

O 

I 

h 

UJ 

£ 

FIXED  ALPHANUMERIC  DISPLAYS 

v&'&Sn 

7  ; 

:  •.  ;f  ':7 

"Tv./: 

/■v.  • . 

LISTS 

4 

1* 

2 

3 

PRESTRUCTUREO  FORMATS 

i 

1 

2 

2 

2 

HELPS 

4 

1 

2 

i 

4 

ERROR  MESSAGES 

4 

2 

3 

4 

i 

VARIABLE  ALPHANUMERIC  DISPLAYS 

'  '•  v:: 

i.O-'-'i 

V 

:/y7 

FREE  TEXT  REPORT 

2 

2 

1 

4 

4 

SHOEBOX  (PERSONNEL)  FILES 

2 

2 

1 

2 

2 

•Recommended  is  HI  choke  for  junderdUdUoit  Purposes. 
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2.1.6  ADVISORY  COMMENTS  FOR  ALPHANUMERIC  DISPLAYS 

a.  Fixed  alphanumeric  displays 

1.  Build  fixed  formats  for  alphanumeric  data  in  accordance 
with  the  source  data.  Allow  space  for  the  longest  legal 
entry;  if  grouping  of  data  elements  is  required,  make  the 
groupings  agree  with  those  of  the  source  data.  Do  not 
vary  formats  for  identical  data  element  structures. 

2.  Give  each  display  frame  a  unique  identifier,  i.e.,  a  name 
or  a  number.  When  multiple  frames  are  necessary  to  com¬ 
plete  a  display,  give  each  display  frane  an  identifier 
which  shows  how  that  frame  fits  into  the  total  picture. 

EXAMPLE:  PERS  LIST,  FRAME  1  OF  4 

3.  Identify  all  fixed  fields  with  a  field  label.  Even  fre¬ 
quently  used  fields  having  a  standard  format  need  a  field 
label. 

EXAMPLE:  DATE: _ / _ / _ ;  (for  month,  day,  year.) 

4.  Left  justify  text  and  other  alphanumeric  formatted  data. 
Right  justify  nonerical/tabular  data.  Do  not  require 
leading  zeros  in  numerical  data  except  where  needed  for 
precision. 


EXAMPLE: 

USE 

DO  NOT  USE 

NUMBER  OF  TANKS:  ? 

17 

000017 

NUMBER 

'OF  SOLDIERS:  > 

66 

000066 

RATIO: 

SOLDIERS  TO  TANKS: 

j  3.B82 

0  ..<382 

RATIO: 

TANKS  TO  SOLDIERS: 

l  .258 

000.258 

5.  Design  the  fixed  format  for  data  input  to  match  the  output 
unloss  such  requirements  impose  difficulty  or  overburdening 
on  the  user/ operator. 

6.  When  providing  on-line  HELPS  and/et  error  messages,  present 
them  each  in  a  consistent  format  and  at  a  consistent  loca¬ 
tion  on  the  screen. 

7.  Hake  HELPS  and  error  messages  clear,  concise,  and  self- 
contained.  That  is,  provide  all  necessary  information  for 
helping  in  the  data  entry  or  correction  without  sending 
tha  usor/operator  to  external  data  sources. 

B.  Make  terminology  used  in  HELPS  and  error  messages  consistent 
with  terminology  used  elsewhere  ir.  the  system. 
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$ 

■a 


$ 


ii 

V' 

A. 

.•V. 


2.1-12 


J*  J 


2.1.6 


* .  * .  ’» .  '*  • 

~^i ‘  *  --i-  i*  ~i.‘  i 


9.  When  menus  are  used  to  present  user/operator  options, 

allow  selection  of  a  menu  item  by  a  number  and/or  letters, 
if  appropriate.  Use  "1”  as  the  first  entry.  However, 
when  a  series  of  menus  provides  some  of  the  same  but 
selected  options,  assign  a  consistent  number  to  each  menu 
option.  Always  present  menu  options  in  ascending  numeric 
sequence,  skipping  those  numbers  which  are  inappropriate 
in  a  given  menu. 

10.  When  alpha  or  alphanumeric  information  is  presented  for 
scanning  purposes,  present  the  data  in  a  left-justified 
format.  Use  indentations  to  identify  subclassifications. 

EXAMPLE:  DISPLAY  OPTIONS 
RETRIEVE  DATA 
STORE  DATA 
DISPLAY  DATA 
ALPHANUMERIC 
NUMERIC 
SYMBOLIC 

COMBAT  EQUIPMENT 
AIR  EQUIPMENT 
TRANSPORTATION  EQUIPMENT 
ENTRY  OPTIONS 
STORED  DATA 
SYSTEM  CALCULATION 
USER/ OPERATOR- ENTERED  DATA 

11.  When  standard  categories  of  information  are  presented  in 
a  variety  of  formats  across  the  system,  assign  functional 
fields  to  specific  areas  of  the  format/screen.  In  effect, 
then,  areas  of  the  format/screon  are  reserved  for  partic¬ 
ular  typos  of  information  such  as:  header,  data  entry 
area,  HELPS,  alarms,  error  messages. 

12.  When  columns  of  information  are  displayed,  each  column 
should  have  a  heading.  Use  only  upper-case  letters  for 
headings. 

13.  When  columnar  data  are  presented,  line-by-linc  associ¬ 

ations  should  be  easily  and  u’  atly  apparent.  Providing 
additional  spacing  between  li  •  ■  -u  lacing  columns  close 

together — but  not  so  close  that  entries  bump  into  each 
other— will  help.  Lists  should  have  only  one  item  to  a 
line. 


14.  Align  lists  of  comparable  numerical  data  containing  deci¬ 
mals  by  the  decimal  point. 

EXAMPLE:  USE  DC  NOT  USE 

IS .985  15.88$ 


4.65  4.65 


21,535.621 


l... 

F, 


V  ■ 

E 

i;- 

k 


r 


2 •1-13 


21,535-621 


V_> V >. V VVirKSSK 


2.1.6 


15.  Organize  fixed  formats  on  a  logical  basis  to  eliminate 
the  need  for  excessive  user/operator  movement  of  the  cur¬ 
sor  in  entering  data.  Any  of  a  variety  of  data  grouping 
strategies  may  be  used.  One  of  the  following  organizing 
strategies  may  be  appropriate* 

(a)  Source  data  sequence,  as  found  on  a  listing  or  a 
standard  reporting  format. 

(b)  Time-ordered  sequence,  appropriate  for  demonstrating 
a  chronicle  of  events.  The  nature  of  the  situation 
will  dictate  whether  the  sequencing  should  proceed 
from  "last  to  first"  or  "first  to  last." 

(c)  Frequency  of  use,  placing  those  categories  of  infor¬ 
mation  more  routinely  used  at  the  beginning  of  the 
format  and  those  categories  used  only  infrequently 
at  the  end  of  the  format.  When  such  a  structure  is 
used  in  a  multiple  series  of  displays  per  format, 
allow  the  user/operator  to  "escape"  when  no  further 
entries  are  to  be  made. 

(d)  importance  or  immediacy  to  the  user,  placing  the 
most  imperative  or  critical  data  at  the  beginning 
of  the  format. 

(e)  Use  sequence,  placing  that  data  most  frequently  used 
at  the  beginning  of  the  format  or  grouping  categories 
of  data  together  on  the  basis  of  the  frequent  associ¬ 
ation. 

When  conflicts  arise  among  the  above  strategies,  an  arbi¬ 
trary  selection  of  formatting  priority  is  required. 

16.  Permit  the  user/oparator  to  scroll  back  and  forth  between 
screens  when  working  with  a  multiple  screen  display. 

17.  Allow  the  user/operator  when  completing  data  entry  in  a 
fixed  format  to  delete  unprotected  data  from  an  output 
as  appropriate  to  the  task.  Do  not  permit  the  user/ 
operator  to  delete  protected  fields  even  if  no  entry  is 
required  in  that  field. 
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b.  Variable  alphanumeric  displays 

NOTE:  Many  advisory  comir.ants  provided  for  fixed  alphanumeric 
displays  may  also  be  appropriate  to  variable  alpha¬ 
numeric  displays  in  the  sense  that  once  the  display 
parameters  are  selected  they  become  "fixed,"  at  least 
for  that  application.  These  considerations  may  be 
particularly  relevant  to  the  development  of  shoe  box 
or  personal  files  which  may  later  be  incorporated  into 
standard  fixed  displays.  Thus,  the  preceding  advisory 
comments  for  fixed  alphanumeric  displays  should  be 
reviewed  for  applicability  to  construction  of  specific 
variable  alphanumeric  displays. 

1.  In  free  text  output  messages,  avoid  hyphenation  of  words 
at  the  end  of  a  line.  If  hyphenation  is  used,  have  the 
system  apply  simple  rules  for  breaking  words  into  conven¬ 
tional  syllables. 

2.  In  free  text  output,  specify  a  sentence  word  length  limit 
and  provide  a  warning  to  the  user/operator  that  the 
sentence  length  limit  has  been  reached  or  exceeded.  This 
encourages  the  user/operator  to  construct  simple  straight¬ 
forward  sentences. 

3.  In  free  text  construction,  permit  the  user/operator  to 
determine  output  parameters  such  as:  upper/lower  case, 
line  length,  spacing,  heading  style  and  placement, 
indentations. 

4.  Allow  the  user/operator  to  organize  the  screen  for  data 
entry  or  output  as  appropriate  to  the  task.  The  type  of 
data  will  indicate  whether  output  should  be  textual  or 
tabular,  formatted  or  unformatted. 

5.  The  system  noeds  to  know  that  it  has  come  to  the  end  of 

a  display  when  display  construction  and  length  are  at  the 
discretion  of  the  user/oporator .  Require  the  user/oporator 
to  provide  a  notation  such  as  "END  OF  DISPLAY"  or  “END  OF 
LIST"  before  the  system  can  process  the  display. 

0.  Make  sample  displays  showing  good/roadable  output  acces¬ 
sible  to  the  usor/operator  through  the  system.  Sample 
displays  should  bo  representative  of  textual  and  tabular 
presentations,  and  attend  to  such  parameters  as  line  and 
column  separations,  density  of  the  screen,  and  use  of  high¬ 
lighting. 
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2,2  Graphics  Displays 


2.2.1  DEFINITION 

Graphics  displays  are  screen  or  hard  copy  diagrammatic  or  pictorial 
presentations.  The  information  provided  here  on  graphics  displays  describes 
conditions  and  techniques  for  their  utilization  as  well  as  display  character¬ 
istics.  In  addition  to  providing  guidance  for  the  design  of  the  graphics 
display,  these  guidelines  also  address  the  content  and  composition  of 
alphanumeric  information  which  supports  the  graphics  presentation. 
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2.2.2  APPLICATIONS  FOR  GRAPHICS  OISPLAYS 

Use  of  graphics  displays  is  particularly  appropriate  for: 


a. 


Display  of  relative  quantities  or  other  measures  of  things. 

EXAMPLE:  The  commander's  briefing  requires  presentation  of 
relative  strengths  of  friendly  and  enemy  tank  forces  within 
a  given  battle  zone.  A  frequency  polygon  is  generated  in  which 
a  stylized  diagram  of  a  tank  represents  a  tank  platoon.  Friendly 
forces  are  shown  m  green;  enemy  forces  are  shown  in  red.  itera¬ 
tive  caliup  of  the  representational  tank,  linear  placement  of  suc- 
polygon  tankS'  anu  c°loration  permit  generation  of  the  frequency 


b*  Representational  presentation  of  relationships. 

EXAMPLE:  The  commander's  briefing  also  requires  presentation 
ot  the  organizational  structure  of  a  group  of  field  units. 

As  well  as  depicting  the  command  structure,  the  type  of  com¬ 
munication  links  between  field  units  is  to  be  displayed.  Com¬ 
mand  structure  is  draw  as  an  organization  chart.  Various 
shape  codes  are  used  to  differentiate  unit  levels;  different 
colors  are  used  for  connecting  lines  to  demonstrate  communica¬ 
tion  channels  and  type  between  units  and  organizational  levels. 

c*  gjsplay  of  topographic  features  in  a  representational  framework. 

EXAMPLE:  in  a  system  which  provides  data  processing  support 
to  tact leal  command  and  control,  a  graphics  capability  is  pro¬ 
vided.  Maps,  which  are  displayed  on  a  plasma  screen,  can  be 
enhanced  by  u n t r y / d e 1 e t i on/mo veme n t  of  special  symbols  and 
creation  of  additional  symbols— all  through  use  o£  a  series  of 
ixed  function  keys.  The  generated  symbols  (whether  standard 
doctrinal  symbols  or  newly  created  symbols)  can  be  superin*K>$ea 
on  a  displayed  map  to  demonstrate,  for  example,  current,  future, 
or  historical  status  of  a  given  geopolitical  area.  Or.  successive 
overlays  can  be  prepared  to  show  a  variety  of  topographic  fea¬ 
tures,  e.g.,  terrain  features,  cultural  features,  rainfall. 


Creation  of  "free  form"  drawings  and  sketches . 

EXAMPLE:  An  artillery  system  projects  battle  strategies  on  the 
fasts  vf,  for  example,  terrain  and  cultural  characteristics, 
fire  pwer.  personnel,  and  interim  battle  outcome  parameters. 

The  tank  commander,  working  on  a  map  grid  of  the  battle  are 
creates  various  map  overlays  to  aid  in  the  planning  of  battle 
strategies.  Strategies  can  reflect,  for  example,  destroyed/tvot 
destroyed  terrain  and  cultural  features;  personnel  levels  available 
as  a  result  of  battle;  gun  availability  and  ascw  levels;  terrain 
conditions  for  tank  movement.  This  system  does  net  have  the 
capability  to  deal  with  real-time  events  on  an  automatic  basis, 
however,  the  capacity  to  deal  with  time-bound  events  (e.g.,  rate 
o.  advance ,  time  ir  cv^pldte  a  maneuver)  permits  the  tank  commander 
fo  project  time  into  the  battle  strategy. 
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Display  of  imagery. 

EXAMPLE:  Certain  types  of  "field  information"  are  required  to 
be  maintained  on  a  continuing  basis  at  headquarters.  These  data 
are  measured  and  transmitted  automatically  as  telemetered  data. 

At  the  receiving  station  at  headquarters,  the  pulses  are  converted 
to  automatic  graphics  output,  sometimes  in  the  form  of  line  draw¬ 
ings,  sometimes  in  the  form  of  bar  charts,  sometimes  in  the  form 
of  color  graphics. 
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2.2.3  BENEFITS  OF  GRAPHICS  DISPLAYS 

Use  of  graphics  displays  has  the  following  benefits  for  overall  system 
performance : 

a.  Reduced  error  rates,  by  minimizing: 

1.  Inability  of  the  user /operator  to  clearly  discriminate 
symbology  or  to  misinterpret  the  meaning  of  display  sym¬ 
bols. 

2.  Accidental  selection  of  the  wrong  symbol(s). 

3.  Failure  to  follow  the  correct  line  in  multivariable  trend 
displays. 

4.  Misestimation  of  parameter  values  in  quantitative  presen¬ 
tations. 

5.  Failure  to  correctly  identify  depicted  installations  or 
equipment  due  to  inadequate  contrast  or  resolution  in  the 
soft  copy  display  or  in  the  conversion  from  soft  copy  to 
hard  copy. 

b.  Increased  system  throughput  rates,  by  minimizing: 

1.  Time  required  to  locate  desired  information. 

2.  Time  involved  in  intergrating  information. 

3.  Time  required  to  correct  errors  of  identification  and 
interpretation . 
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2.2.4  METHODS  FOR  GRAPHICS  DISPLAYS 

a.  Bar  graph,  bar  chart,  histogram.  These  are  common  names  for  a 
graphics  display  which  consists  of  a  series  of  bars  or  rectangles 
with  lengths  proportional  to  specific  quantities  of  a  measured 
item.  In  this  instance  the  bar  graph  might  be  representing  the 
number  of  tanks  to  be  delivered  to  dn  armored  division  each 
successive  week  over  a  ten-week  period.  Or,  the  bar  graph  might 
be  reporting  the  number  of  tanks  damaged  daily  over  a  ten-day 
period.  In  thi.3  example,  time  is  shown  along  the  horizontal  axis 
and  the  proportional  value  is  shown  vertically. 


Bar  graphs  can  also  be  oriented  in  a  horizontal  direction,  as 
shown  below.  This  display  might  be  reporting,  for  example, 
average  unit  strength  per  year  over  a  five-year  period.  In 
this  instance,  time  is  set  along  the  vertical  axis  and  unit 
strength  is  shown  horizontally. 


Sample  horizontal  bar  graph. 
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Pie  chart.  The  pie  chart  is  another  form  of  graphics  display 
for  demonstration  of  quantitative  relationships.  A  primary 
difference  in  application  between  pie  charts  and  bar  charts, 
as  well  as  between  pie  charts  and  frequency  polygons,  is  that 
the  pie  chart  readily  communicates  not  just  relative  amounts 
but  the  quantity  as  a  portion  of  the  whole. 
- - - 


- - - - - / 

Samp  .e  pie  chart. 


d.  Flow  chart,  organization  chart.  Flow  charts  and  organization 
charts  demonstrate  nonquant itative  relationships.  Typically, 
these  graphics  deal  with  positional,  hierarchical,  functional, 
or  sequential  relation  hips.  The  following  flow  chart  demon¬ 
strates  the  sequence  of  actio-  3  required  in  TACFIRE's  prepara¬ 
tion  of  a  schedule  of  fires. 
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Sample  flow  chart. 
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The  following  flow  chart  permits  ready  comprehension  of  the  com¬ 
ponents  and  univ  relationships  of  the  aerial  surveillance  func¬ 
tion  of  a  military  intelligence  company.  This  display  also 
indicates  that  there  are  18  fixed-wing  OV-ID  planes  which  furnish 
data  and  that  a  data  terminal  section  within  the  company  is  an 
optional  configuration. 
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Sample  organization  chart. 


Map,  map  overlay,  and  chart.  Maps  and  charts  are  very  ver¬ 
satile  forms  of  graphics  displays.  Maps  usually  depict  the 
topographic — the  natural  and/or  manmade — features  of  a  geo¬ 
graphic  area.  The  term  chart  is  usually  used  to  refer  to 
navigational  maps  showing  coastlines,  water  depths,  celestial, 
or  other  information  of  use  to  navigators. 


r 


\ 


v. 

Sample  map. 
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Map  overlays  permit  conversion  of  a  basic  map  to  maps  which 
feature  particular  aspects  of  the  geographic  area,  e.g.»  elevation 
rainfall,  equipment  emplacement.  The  following  figure  uses  an 
overlay  with  symbolic  notations  to  indicate  both  terrain  features 
and  equipment  placement. 


Sample  map  overlay. 


Line  drawing.  The  capability  to  create  line  drawings  makes  the 
system  very  powerful  in  terms  of-  the  types  of  information  which 
can  be  generated.  Almost  any  kind  of  "representation,”  from 
abstract  to  near  photographic  quality,  can  be  produced.  The 
following  line  drawing  depicts  fire  control  geometry  measures, 
as  follows: 

Zone  of  responsibility 
Fire  coordination  area  (FCA) 

Front  line  trace  (FRLT) 

No  fire  line  (NFL) 

Fire  coordination  line  (FCL) 

Air  corridor 


Sample  line  drawing. 
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2.2.5  RECOMMENDATIONS  FOR  GRAPHICS  DISPLAYS 


a.  Use  graphics  displays  when  demonstrating  simple  operational  rela¬ 
tionships  to  the  user/operator. 

b.  Allow  the  user/operator  to  generate  graphics  displays  when  demon¬ 
strating  quantitative  relationships  of  data  categories. 

c.  Use  graphics  displays  for  the  presentation/interpretation  of  data 
generated  through  automation. 

d.  Do  not  use  graphics  displays  when  an  excessive  number  of  data 
parameters  is  included.  A  3  x  7  format  is  probably  maximum  for 
most  quantitative  graphics  formats. 

e.  Do  not  use  graphics  displays  for  quantitative  data  when  measures 
are  inordinately  out  of  balance.  Relationships  on  the  order  of 
from  2  to  10  to  one  are  appropriate  for  graphics  display.  Rela¬ 
tionships  on  the  order  of  50  to  100  to  one  are  inappropriate. 

f.  Add  alphanumeric  tag  and  annotation  capability  to  graphics  dis¬ 
plays  capabilities  to  enhance  their  meaningfulness. 

g.  Table  2.2-1,  Method  of  Graphics  Display  by  Application,  presents 
general  recommendations  for  the  use  of  particular  displays  accord¬ 
ing  to  the  type  of  output  required  by  the  user/operator. 


Table  2.2-1.  Method  of  Graphics  Display  by  Application 
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2.2.6  ADVISORY  COMMENTS  FOR  GRAPHICS  DISPLAYS 


a.  Bar  graph,  bar  chart,  histogram 

1.  Label  the  axes  of  bar  graphs,  bar  charts,  and  histograms 
using  consistent  terminology  and  *  .  cement.  Labels  for 
the  x-axis  are  generally  centered  and  written  horizontally. 
Labels  for  the  y-axis  are  also  generally  centered,  but 
written  vertically. 

2.  Use  only  upper-case  letters  for  labels. 

3.  Use  mathematically  meaningful  subdivisions  for  intervals 
along  the  axes.  For  example,  intervals  of  1,  2,  5,  and  10 
are  easily  handled  mentally.  Seven  is  not  usually  a  good 
interval  since  it  is  not  divisible.  However,  if  the  user/ 
operator  is  constructing  week-by-week  information  on  a 
daily  report  basis,  secondary  intervals  indicating  the 
seven  days  of  the  week  are  appropriate. 

4.  Make  separations  and  distinctions  between/among  different 
data  readily  apparent  by  using  shading  and/or  color  coding. 

5.  Keep  a  good  balance  in  the  bar  graph,  chart,  or  histogram. 
Long  skinny  "sticks"  with  wide  spaces  between  them  are  poor 
layout.  Use  wider  columns  with  smaller  spaces  between  the 
columns  so  that  comparisons  and  actual  data  readings  are 
easier  to  make. 

6.  Do  not  over-identify  points  along  the  axes.  Intervals  of 
5,  for  example,  can  be  marked  and  annotated  at  only  the 
“tens"  intervals  and  still  communicate  the  5-level  intervals 
very  readily.  On  the  other  hand,  providing  annotation  at 
only  every  fourth  or  fifth  interval  causes  confusion  in 
interpretation. 

7.  Do  not  attempt  to  put  excessive  amounts  of  data  into  a 
single  chart;  make  multiple  charts  instead.  The  point  of 
the  graphics  display  is  to  provide  rapid  and  accurate 
communication  of  the  "sense”  of  the  data.  Provide  the  raw 
data — preferably  in  tabular  form- -as  back-up. 

b.  Frequency  polygon,  trend  analysis 

NOTE:  Because  of  the  comparability  of  layout,  many  of  the 
advisory  comments  provided  for  the  bar  graph,  bar 
chart,  and  histogram  aro  appropriate  to  the  frequency 
polygon  and  to  trend  analysis.  Review  those  advisory 
comments  for  applicability  to  construction  of  specific 
aspects  of  frequency  polygons  and  trend  analysis. 

1.  If  trends  are  to  be  compared,  place  multiple  trend  lines 
on  a  single  grid  rather  than  using  multiple  grids  with 
only  a  single  trend  line  per  grid. 
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2.  Provide  unique  trend  line  symbols  when  trend  lines  intersect. 

3.  When  line  crossings  are  such  that  intersections  can  become 
confused,  use  unique  trend  line  symbols  as  well  as  unique 
line  structures  (solid,  dashed,  dotted  lines,  and  combina¬ 
tions  thereof) . 

4.  If  the  system  has  a  color  graphics  capability,  use  color 
coding  of  lines  to  help  eliminate  line  crossing  confusions. 
Color  coding  can  be  used  to  substitute  for  line  structure 
coding  or  to  amplify  the  line  structure  coding. 

Pie  chart 

1.  Provide  a  clear  label  for  each  segment  of  the  pie  chart. 

When  a  given  segment  of  the  pie  chart  is  too  small  to  hold 
the  label,  place  the  label  outside  the  segment  and  draw  an 
arrow  to  the  segment. 

2.  when  the  user /operator  might  have  need  for  the  actual  data 
rather  than  just  make  comparisons  (e.g.,  76%  and  14%  versus 
"larger"  and  "smaller"),  provide  the  actual  numerical  nota¬ 
tions  within  the  segment.  Again,  if  there  is  not  space 
within  the  segment  to  claarly  indicate  the  value,  place  it 
outside  and  draw  an  arrow  to  the  appropriate  segment. 

3.  Place  upper  and  lower  limits  on  the  number  of  segments 
the  user/operator  can  include  in  the  pie  chart.  A  minimum 
of  3  segments  and  a  maximum  of  9  is  probably  appropriate, 
although  in  some  instances  2  segments  might  be  a  useful 
display.  If  data  are  such  that  more  than  9  segments  are 
possible,  it  will  likely  be  useful  to  combine  the  smaller 
data  elements  into  one  group  labeled  "other."  Under 
those  circumstances,  provide  such  a  message  to  the  user/ 
operator . 

4.  Adding  color  to  pie  cliarts  provides  another  dimension  by 
which  to  make  categorical  comparisons  stand  out.  Use 
colors  in  such  a  fashion  so  that  adjacent  colors  are 
complementary  rather  than  obtrusive  and  so  that  they  do 
not  create  an  interactive  “blooming"  or  obliterating 
effect . 


Plow  chart,  organisation  chart 


1.  Use  flow  charts  and  organisation  charts  to  communicate 
relationships  among  things  and  units  and  aspects  of  those 
relationships.  When  properly  constructed,  these  charts 
can  communicate  relationships  more  quickly  and  concisely 
than  textual  information.  When  inserted  into  textual 
presentations,  flow  charts  and  organisation  charts  support 
the  textual  presentation. 
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2.  Symbolic/shape  coding  of  elements  contained  in  flow  charts  ! 

and  organization  charts  provides  a  method  for  adding  param-  [ 

eters  of  information  or  making  distinctions  between  classes  . 

or  elements. 

3.  Use  color  coding  of  lines  to  demonstrate  different  types  I 

of  relationships  among  elements  included  in  the  chart.  j 

t 

4.  Always  provide  a  key  to  symbolic  and  color  codes.  \ 

\ 

5.  A  great  variety  of  detailed  information  can  be  displayed  i 

through  the  combination  of  symbolic  and  color  coding  of  < 

elements  of  flow  charts  and  organization  charts.  However,  j 

be  careful  not  to  overrule  the  intended  simplicity  by  I 

incorporating  too  many  dimensions  of  symbolic  and  color  t, 

coding  into  the  chart.  J 


Map,  map  overlay,  chart 

1.  Use  standard/doctrinal  symbology  on  maps,  map  overlays, 
and  charts  when  available. 

2.  When  standard  symbols  have  not  been  identified  for  specific 
things,  features,  or  conditions,  make  simple,  clear,  dis¬ 
tinctive  symbols  as  representative  as  possible,  stick  to 
meaningful  graphics  construction.  Use  consistent  symbols 
from  situation  to  situation  so  that  symbology  has  consistent 
meaning  within  the  system,  at  least. 

3.  Position  symbols  on  the  map  grid  at  exact  locations.  When 
this  is  not  possible,  position  the  symbol  near  the  location 
and  draw  an  arrow  to  the  exact  location.  For  accuracy  pur¬ 
poses  in  some  instances,  it  will  be  necessary  to  provide 
coordinates  of  the  exact  location  along  with  the  symbol. 

4.  Do  not  draw/place  one  symbol  over  another  unless  thoy  con 
both  be  clearly  and  unambiguously  identified. 

5.  Orientation  of  the  map  symbol  may  be,  in  some  instances, 
as  important  as  the  location  of  the  symbol. 

6.  The  positional  accuracy  of  symbols  (or  even  their  deletion) 
is  affected  by  the  speed  with  which  tho  symbol  manipulation 
is  made. 

7.  Color  and  shading  are  important  dimensions  in  map  con¬ 
struction  and  permit  a  great  variety  of  detail.  Be  awaro, 
however,  of  interactive  effocts  of  colors  and  of  color 
shading.  Tho  addition  Of  too  much  detail  through  symbolic, 
color,  and  shading  coding  will  obscure  tho  intended  moaning 
of  the  map. 
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Line  drawing 

1.  Allow  the  user/operator  to  use  line  drawings  as  illustra¬ 
tions  to  support  textual  information. 

2.  The  accuracy  and  quality  of  the  line  drawing  often  is 
affected  by  the  speed  with  which  it  is  made.  Take  quality 
and  accuracy  requirements  into  account  when  making  line 
drawings. 
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2.3  Selective  Highlighting 


2.3.1  DEFINITION 

Selective  highlighting  is  the  application  of  illumination,  color,  graphics, 
and/or  other  techniques  to  produce  visual  effects  which  announce  clearly  to  the 
user/operator  that  selected  portions  of  a  display  have  greater  importance  or 
significance  than  other  portions.  Highlighting  is  appropriate  to  any  of  the 
display  types  previously  discussed.  However,  methods  and  applications  of 
highlighting,  as  well  as  purpose,  differ  by  display  type.  Highlighting  makes 
it  easier  for  the  user/operator  to  find  and  keep  track  of  the  most  important 
or  critical  information  in  the  display. 


A 


EXAMPLE:  A  logistics  system  highlights  types  of  equipment 
which  are  below  recommended  levels  in  a  given  company . 

b.  To  identify  information  which  has  been  changed  during  editin 


or  some  other  form  of  data  entry. 


EXAMPLE:  A  user/operator  changes  the  number  of  heavy  tanks 
in  the  Order-of-Battle  File  for  an  armored  division  of  a 
potential  aggressor.  Before  the  new  information  is  stored, 
the  system  presents  the  user/operator  with  a  list  of  some 
of  the  most  important  features  of  that  portion  of  the  Order- 
of-Battle  File.  In  this  list,  the  items  which  the  user/ 
operator  has  changed  are  highlighted. 

To  specify  information  which  should  be  changed  during  editing 


or  another  form  of  data  ent 


EXAMPLE:  A  file  of  information  has  been  updated  by  reading 
a  number  of  cards  into  the  file.  Some  of  the  entries  are 
wrong.  An  interactive  portion  of  the  system  presents  the 
data  which  have  been  entered  into  the  system,  with  the 
erroneous  data  (as  detected  by  the  computer)  highlighted. 

d.  To  call  attention  to  high  priority  codes  or  messages. 

EXAMPLE:  In  an  artillery  data  system,  the  usor/opcrator 
must  ha  certain  that  the  target  coordinates  for  a  fire  mission 
do  not  mean  that  friendly  fire  will  impact  on  friendly  forces. 
The  data  indicating  those  coordinates  is  therefore  highlighted 
when  it  is  displayed. 

e*  To  indicate  the  naturo  of  alarms. 

EXAMPLE.  In  a  communications  system,  the  user/operator  must 
decide  how  to  distribute  massages  down  the  chain  of  command. 
While  reviewing  a  set  of  relatively  routine  messages,  an 
urgent  transmission  is  received  digitally.  In  a  designated 
portion  of  the  CRT  display,  the  receipt  of  the  urgent 
message  is  indicated  and  the  source  (or  other  information) 
of  the  message  is  highlighted. 

f.  To  call  attention  to  special  areas  or  features  of  the  display. 
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g.  To  Indicate  data  entry  error  or  command  entry  error. 

EXAMPLE:  In  a  logistics  system,  the  user/operatcr  is  required 
to  enter  codes  for  equipment  types  for  which  information  is  to 
be  retrieved.  The  system  highlights  the  characters  in  the  data 
string  which  are  not  valid. 

h.  To  provide  warning  of  the  consequences  of  a  given  command  entry. 

EXAMINES:  In  a  system  which  stores  and  provides  for  update  of 
order-of -battle  information,  a  user/operator  specifies  the 
deletion  of  a  particular  type  of  data  element  from  the  entire 
Order-of-Battle  File.  The  system  prints  out  a  message  warning 
the  user/operator  that  execution  of  this  command  will  require 
several  hours,  and  that  the  information  contained  in  this  data 
file  will  no  longer  be  available  on-line.  This  message  is 
highlighted. 

i.  To  identify  search  targets. 

EXAMPLE:  An  intelligence  system  displays  the  location  of 
potential  aggressor  units  on  a  map  display.  For  the  purposes 
of  planning  fox  a  particular  operation,  the  user /operator  is 
particularly  concerned  about  the  location  of  armored  units. 

By  entering  the  appropriate  command,  the  user/operator  causes 
the  symbols  indicating  armored  units  to  be  highlighted  on  the 
display. 

j.  To  differentiate  among  different  levels  of  a  multivalued  variable. 

EXAMPLE:  Ammo  available  is  displayed  on  a  status  board  for 
the  Coranander's  briefing.  Adequacy  of  available  ammo  is 
depicted  by  a  color  code:  green  ®  adequate  supply:  yellow  « 
close  to  minimum  requirements:  red  »  below  minimum  requirements. 
The  percentage  at  which  the  color  indications  appear  vary 
according  to  peace tise/bat tie  condition. 

k.  To  locate  the  screen  area  where  the  "next  action"  will  take  place. 

EXAMPLE:  In  an  administrative  system,  the  user/operator  must 
enter  requests  for  medical  supplies  into  a  prestrucfcured  format 
which  requires  the  drug  supply  code,  the  sire ,  and  the  quantity 
in  a  columnar  format.  A  blinking  cursor  indicates  where  the 
nest  keyed-in  data  entry  will  appear. 

l.  To  indicate  need  for  data  or  command  entry. 


EXAMPLE:  In  a  field  artillery  system  the  user/operator ,  when 
planning  a  firing  mission ,  has  the  option  o?  providing  same 
types  of  data  but  some  type®  of  data  must  be  entered  before 
the  messages  can  be  forwarded.  If  the  instruction  to  forward 
the  message  is  rejected  because  of  missing  essential  lata, 
the  data  field  label  blinks  until  the  field  is  filled  in. 


A 

t 


1 


tes 

.  < 


Tt 


ss 


V, 


%  * 


rv 


2.1-3 


2.3.3  BENEFITS  OF  SELECTIVE  HIGHLIGHTING 

Appropriate  utilization  of  selective  highlighting: 
a.  Reduces  error  rates,  by  minimizing: 

1.  Failure  to  perceive  or  attend  to  significant  or  important 
items  of  information. 

2.  Confusion  about  operational  requirements. 


b.  Increases  system  throughput  rates,  by  minimizing: 

1.  Time  to  recognize  and  attend  to  important  or  significant 
information. 

2.  Time  associated  with  differentiation  of  the  priorities 
of  requirements  or  information. 
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NO  NATCH  ON  FILE  NAME  “CHKSUH1 
DO  yOU  KISH  TO: 


1 .  ENTER  A  NEW  RETRIEVAL  NAME 

2.  REVIEW  THE  VALID  FILE  NAMES 

3.  PERFORM  ANOTHER  OPERATION 


.acter  size  control.  The  in: 


^resented  in  larger  characte: 
>e  highlighted. 


— — - i 

NO  MATCH  ON  FILE  NAME  "CHKSUN* 


DO  YOU  WISH  TO: 

1.  ENTER  A  NEW  RETRIEVAL  NAME 

2.  REVIEW  the  valid  file  nahes 

3.  PERFORM  another  operation 


NO  MATCH  FOUND  ON  FILE  NAME  “CHKSUM1 
00  YOU  NISH  TO: 


1.  ENTer  a  new  retrieval  name 

2.  REVIew  the  valid  file  names 

3.  PERform  another  operation 


l. 


Reverse  video  or  reverse  display.  The 
or  characters  and  the  colors  of  the  ba 
are  presented  are  reversed. 


NO  MATCH  FOUND  ON  FI1.6  "CHKSUM" 


00  YOU  WISH  TO: 


1.  ENTER  A  NEW  RETRIEVAL  NAME 
j[.  REVIEW  THE  VALID  FILE  NAME 
1.  PERFORM  ANOTHER  OPERATION 


T 


Underlinin 


HATCH  FOUND  ON  FILE  NAME  “CHKSUM“ 


DO  YOU  NISH  TO: 

1.  ENTER  A  NEW  RETRIEVAL  NAME 

2.  REVIEW  THE  VALID  FILE  NAMES 

3.  PERFORM  ANOTHER  OPERATION 


r 

NO  HATCH  FOUND  ON  FILS  NANS  "CHKSUH" 

00  YOU  WISH  TO: 

I. 

INTER  a  new  retrieval  name 

2. 

wrvIEW  THE  VALID  FILE  NAMES 

•J. 

PERFORM  another  operation 

— > 
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Boxing  or  surrounding.  The  highlighted  information  is  con 
tained  within  a  box  formed  by  lines  or  symbols. 


r 

1  **************************************** 

*  NO  HATCH  FOUND  ON  FILE  NAffi  “CHKSUH"  * 

*** 

***** 

*1* 

*** 

*ENT*ER  A  NEW  RETRIEVAL  NAME 
***** 

*** 

***** 

*♦* 

♦REVIEW  THE  VAUO  FILE  NAMES 
***** 

#** 

*3* 

*** 

•PERFORM  ANOTHER  OPERATION 

***** 

— > 

L 

A 

Arrowing .  An  arrow  drcwn  on  the  display  indicates  that 
an  item  in  the  display  is  worthy  of  special  attention. 
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k.  Symbolic  tagging.  A  symbol  located  near  an  item  or  group 
of  items  on  the  display  indicates  that  it  (they)  are  worthy 
of  special  attention. 


1.  Alphanumeric  tagging.  Groups  of  characters  located  near  infor¬ 
mation  in  the  display  indicate  that  these  items  are  Important. 

( 


m.  Position  displacement.  Information  is  highlighted  by  moving 
it  out  of  its  "normal"  position. 


THE  FOLLOWING  IS  AM  ALPHABETIZED  LISTING  Of  THE  PERSONNEL  IN  THE 
THIRD  ARMORED  BATTALION  WITH  HISHEA  THAN  AVERAGE  RATINGS  BY 
SUPERIORS: 


AARONS,  A.J.,  SP-4 
ABRAMS,  B.F.,  SP-S 
ANDERSON,  H.F..  SP-4 
BUTLER,  F.C.,  E-J 
CAYANAUGN,  R.T.,  SP-S 
CELLINI,  B.T.,  E-5 
COSKOHITZ,  R.T.,  SP-5 
OOTLICH,  6.L.,  E-4 
ERHANDO,  S.R.,  SP-4 
EXETER,  0.0. ,  £-5 
PRANCESCA,  H.J.,  SP-S 
CALLOWAY.  O.L.,  SP-S 
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2.3.5  RECOMMENDATIONS  FOR  SELECTIVE  HIGHLIGHTING 

a.  Table  2.3-1,  Method  of  Selective  Highlighting  by  Type  or  Format 
of  Output  Display,  presents  a  general  list  of  recommendations 
for  the  use  of  particular  types  of  highlighting  according  to 
the  type  of  output  device  which  the  user/operator  will  be  view¬ 
ing.  Before  making  a  final  decision  on  the  method  of  selective 
highlighting,  be  sure  to  consult  the  chart  showing  recommenda¬ 
tions  for  highlighting  method  for  particular  applications 
(Table  2.3-2),  as  well  as  the  detailed  discussion  of  highlight¬ 
ing  methods  presented  in  Section  2.3.6,  Advisory  Comments  on 
Methods  of  Selective  Highlighting. 

b.  Use  selective  highlighting  to  indicate  information  in  a  display 
which  is  significantly  more  important  them  other  information  in 
the  display. 

c.  Use  highlighting  when  it  is  desirable  to  gain  the  attention  of 
the  user/operator. 

d.  do  not  use  selective  highlighting  when  the  amo’int  of  informa¬ 
tion  to  be  highlighted  exceeds  ten  percent  of  the  total  infor¬ 
mation  in  the  display. 


Table  2.3-1.  Method  of  Selective  Highlighting  by  Type  or  Format 
of  Output  Display 


MY: 

1  -  RECOMMENDED 

2  •  acceptable 

3  -  WORKABLE  BUT 

OPTIMAL 

«  -  NOT  AECOMHENOEO  OR 

NOT  applicable 

TYPE  OR  MEDIUM  OF  DISPLAY 

Alphp- 

nu»«rlc 

CRT 

Tgraf n|t 

Grpphlt 

CRT 

Tprulnpl 

Alpha* 
nu»«rlt 
Kprd  Copy 
T*r«1nil 
or 

Prlntpr 

Plotter, 

Prlntpr/ 

Plotter 

Jrlghlnttj  Casual 

1* 

4 

4 

Chpriettr  Slip  Control 

1 

1 

.  ♦ 

.  a 

All  Upppr  Con 

2 

2 

2 

2 

Apypmp  Otipliy 

1 

1 

4 

4 

IMotfllnlng 

2 

2 

2 

2 

§ 

Olfftftnt  font 

2 

2 

1 

2 

i 

Color  Control 

4 

1 

4 

1 

Blinking,  Pointing 

3 

3 

4 

4 

2 

1 

2 

i 

Arrowing 

4 

2 

4 

2 

Syoboll*  Tigging 

4 

« 

4 

2 

AlpN»n\*trlt  Tpjglng 

3 

3 

3 

3 

Petition  fllto'ACW'l 

3 

3 

3 

3 

•  OOMAdft)  II  \%\  Cfcott*  for  Ptffpom. 


I 


2.3.6 


£09 


2.3.6  ADVISORY  COMMENTS  FOR  SELECTIVE  HIGHLIGHTING 

a.  Brightness  control 

1.  Do  not  use  brightness  control  when  more  than  three  levels 
of  brightness  are  employed. 

2.  Do  not  use  brightness  control  when  the  lighting  in  the  area 
where  transactions  must  be  performed  is  too  bright  to  per¬ 
mit  adequate  discrimination  of  brightness  levels  in  the 
display. 


Do  not  use  brightness  control  when  the  amount  of  illumina¬ 
tion  coming  from  the  display  will  increase  probability  of 
detection  of  the  user/operator  by  potential  aggressor 
forces. 


4.  Do  not  use  brightness  control  when  its  use  will  cause  the 
user/operator  to  perform  poorly  on  other  tasks  because  the 
excess  light  from  the  display  causes  eye  adaptation  to  the 
brightness  of  the  display. 

Character  size  control 

1.  Do  not  use  character  size  control  whan  it  reduces  the  num¬ 
ber  of  characters  which  can  be  placed  on  the  display  and 
increases  the  number  of  pages  in  a  multi-page  display. 


Do  not  use  character  size  control  where  the  type  of  char- 
actex-  used  in  highlighting  decreases  the  legibility  of  the 
display . 

Do  not  use  character  size  control  where  the  "blooming'*  or 
“blurring”  of  the  larger  characters  decreases  the  legi¬ 
bility  of  other  information  in  the  display. 


1.  Do  not  use  all  upper  case  where  the  legibility  of  the 
highlighted  information  is  important.  Use  of  all  capi¬ 
tal  letters  makes  text  difficult  to  read. 


2.  Do  not  use  all  upper  case  for  highlighting  where  other 
information  on  the  display  would  normally  be  presented 
in  upper  case,  e.g.,  whore  the  display  contains  mili¬ 
tary  acronyms  such  as  ClfiDVAC.  CIKCBUR,  US APS,  etc. 

3.  Do  not  use  all  upper  case  where  it  would  interfere  with 

a  code  scheme  in  which  lower  case  characters  are  required. 
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d.  Reverse  video  or  reverse  display 

1.  Do  not  use  reverse  display  when  its  use  will  cause  the 
user/operator  to  perform  his/her  other  tasks  poorly 
because  excess  light  from  the  display  causes  eye  adapta¬ 
tion  to  the  brightness  of  the  display. 

2.  Do  not  use  reverse  display  when  its  use  increases  the 
amount  of  light  coming  from  the  display,  increasing  the 
probability  of  detection  of  the  user/operator  by  an 
enemy. 

3.  Do  not  use  reverse  display  when  the  "blooming"  or 
"blurring"  caused  by  the  bright  background  decreases 
the  legibility  of  the  display. 

e.  Underlining 

1.  Use  underlining  when  maintaining  the  legibility  of 
highlighted  text  is  crucial. 

2.  Do  not  use  underlining  when  highlighted  characters  and 
underline  appear  on  two  different  display  lines. 

3.  Do  not  use  underlining  when  its  use  will  require  that 
the  number  of  pages  in  the  display  be  increased. 

4.  Do  not  use  underlining  when  the  underlining  cannot  be 
overlaid  on  the  information  to  be  highlighted. 

5.  Do  not  use  underlining  when  "blooming"  or  "blurring" 
caused  by  the  underlining  reduces  the  legibility  of 
highlighted  or  other  characters. 

6.  Do  not  use  underlining  for  highlighting  when  this 
technique  is  already  being  used  for  other  purposes. 

V.  Do  not  use  underlining  for  alarms  or  when  it  is 
crucial  to  gain  the  attention  of  the  user/operatox' 
by  means  of  selective  highlighting. 

f.  Nixed  character  fonts 


x.  Do  not  use  different  fonts  whan  the  font  which  oust 
be  used  for  highlighting  reduces  the  legibility  of 
highlighted  information. 

2.  Do  not  use  different  fonts  when  the  difference  between 
the  two  fonts  is  not  sufficient  to  produce  the  dis¬ 
tinctiveness  required  for  highlighting. 

3.  Do  not  use  different  fonts  when  the  amount  of  informa¬ 
tion  needed  to  construct  characters  in  that  font 
increases  transmission  time. 
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4.  Do  not  use  different  fonts  for  alarms  or  when  it  is 
otherwise  necessary  to  gain  the  attention  of  the  user/ 
operator  by  means  of  selective  highlighting. 

Color  contrast  or  color  coding 

1.  Use  color  coding  when  the  number  of  categories  of  high¬ 
lighting  is  large. 

2.  Use  red  color  coding  if  it  is  desirable  to  avoid  user/ 
operator  adaptation  to  the  brightness  of  the  display. 

3.  Use  the  most  easily  readable  color — usually  yellow-green 
or  white — for  normal  or  unhighlighted  information. 

4.  Use  red  color  coding  for  alarms  or  other  situations 
where  it  is  necessary  to  gain  the  attention  of  the 
user/operator  through  the  use  of  selective  highlight¬ 
ing. 

5.  Use  green  color  coding  to  indicate  normal  or  nonalert 
status. 

6.  Do  not  use  color  coding  when  the  available  colors  are 
of  such  density  and  hue  that  they  are  likely  to  be 
confused  by  persons  with  defective  color  vision. 

7.  Do  not  use  color  coding  if  the  use  of  color  reduces  the 
legibility  of  highlighted  or  other  characters. 

8.  Do  not  use  color  coding  if  lighting  in  the  areas  where 
users/operators  interact  with  the  system  will  cause  the 
colors  to  wash  out. 

Blinking,  flashing,  or  pulsatrng 

1.  Use  blinking  only  for  alarms  or  in  ovher  situations 
where  alerting  or  gaining  the  attention  of  the  user/ 
operator  outweighs  the  irritation  and  reduced  legi¬ 
bility  caused  by  blinking,  flashing,  or  pulsating 
information. 

2.  Use  biinking  only  when  the  highlighted  information 
flashes  “on*  three  to  five  times  per  second. 

3.  Do  not  use  blinking  where  this  form  of  highlighting 
cannot  be  tutred  off  by  the  user/ope rator. 

4.  Do  not  use  blinking  when  the  terminal  to  be  used  has 
long-persistence  phosphors  which  would  cause  the  rate 
of  blinking  to  be  less  than  three  to  five  times  per 
second. 
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i.  Boxing  or  surrc unding 

1.  Use  boxing  when  there  is  a  need  to  highlight  large  amounts 
of  text. 

2.  Use  boxing  to  indicate  "working”  portions  of  a  display. 

3.  Do  not  use  boxing  when  the  information  to  be  highlighted 
is  scattered  more  or  less  randomly  throughout  the  display. 

4.  Do  not  use  boxing  when  this  form  of  highlighting  would 
require  increasing  the  number  of  pages  of  a  display. 

j .  Arrowing 

1.  Use  arrowing  when  there  is  a  need  to  logically  connect 
two  symbols  or  groups  of  symbols  such  as  connecting  the 
code  name  of  an  organization  to  a  chart  symbol  referring 
to  that  organization. 

2.  Do  not  use  arrowing  where  many  items  mast  be  highlighted 
simultaneously. 

3.  Do  not  use  arrowing  to  indicate  items  to  be  scanned. 

4.  Do  not  use  arrowing  to  indicate  alarms  or  other  high- 
priority  messages  and  codes. 

k.  Symbolic  tagging 

1.  Do  not  use  symbolic  tagging  if  other  methods  of  highlight¬ 
ing  are  available. 

l.  Alphanumeric  tagging 

1.  Use  alphanumeric  tagging  where  there  is  a  need  to  provide 
a  code  link  between  a  symbol  on  the  display  and  more 
detailed  information  about  the  tiling  that  the  symbol 
represents,  e.g. ,  use  the  tag  "3  ARM  BN"  to  retrieve 
more  information  about  a  symbol  on  a  map  display  which 
represents  the  position  of  the  third  armored  battalion. 

2.  Do  not  use  alphanumeric  tagging  where  there  is  a  pressing 
need  for  distinctiveness  in  highlighting. 

3.  Os  not  use  alphanumeric  tagging  to  highlight  alphanumeric 
information,  unless  the  tagging  is  accompanied  by  the 
application  of  other  sorts  of  selective  highlighting, 
e.g.,  brightness  control,  position  displacement. 
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m*  Position  displacement 

1.  Use  position  displacement  where  vertically  oriented  lists 
of  information  must  be  rapidly  scanned. 

2.  use  position  displacement  where  displays  which  are  to  be 
scanned  must  be  scrolled. 


SECTION  3.  DATA  ENTRY  AND  HANDLING 

Guidelines  in  this  category  suggest  ways  for  maximizing  the  speed,  accuracy 
and  efficiency  of  user/operator  entry  of  data  into  the  system.  These  guidelines 
encompass  the  following  topics: 

1.  Information  on  Legal  Entries — Deals  with  methods  for  presenting 


the  user/operator  with  information  on  the  content  and  format  of 
data  to  be  entered  into  the  system. 

2.  Unburdening  of  Input — Provides  techniques  which  simplify  the  data 
input  process  and  allow  the  user/operator  greater  ease  in  entering 
data. 

3.  Interrupts  and  Work  Recovery — Presents  methods  for  minimizing 
the  disruption  caused  when  a  processing  halt  occurs  and  for 
maximizing  smooth  transition  during  recovery. 
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3.1  Information  on  Legal  Entries 


3.1.1  DEFINITION 

Information  on  legal  entries  refers  to  information  on  the  format  (the 
structure)  as  well  as  the  content  (the  kind)  of  data  which  comprise  a  legal 
entry.  A  legal  entry  is  that  data  determined  to  be  acceptable  to  the  system? 
it  depends  upon  system  definition.  Criteria  for  making  that  distinction 
include  length  requirement  for  data  entry;  the  data  field;  type  of  element 
being  employed,  whether  it  be  alpha,  numeric,  or  special  characters;  and  the 
appropriate  sequence. 

The  use  of  such  information  provides  the  user/operator  with  the  necessary 


knowledge  to  enter  data  appropriately. 


3.1.2  APPLICATIONS  FOR  INFORMATION  ON  LEGAL  ENTRIES 

Information  on  legal  entries  should  be  provided  to  the  user/operator  when: 

a.  The  format  of  the  information  to  be  entered  is  critical  to  the 
interpretation  of  the  entry  by  the  system. 


EXAMPLE:  In  a  particular  tactical  system,  the  user/operator 
must  enter  the  date  according  to  the  format  YYDDMM;  another  for¬ 
mat,  such  as  DDMMYY,  will  be  incorrect.  Information  on  legal 
entries  permits  the  user /operator  to  determine  the  proper  format. 

b.  The  cones  for  a  data  field  are  limited  in  number  and  rigidly 
.constrained  in  content. 


EXAMPLE:  In  an  order-of-battle  data  exploitation  system,  the 
software  can  recognize  only  certain  codes  specified  for 
particular  equipments.  Thus,  a  user/operator  who  wants  to 
refer  to  the  Soviet  T-72  heavy  tank  must  enter  "VTNK(T72)." 
Entering  "SOVIET  T72,"  "T-72  TANK,"  "SOVIET  HEAVY  TANK,"  "T72," 
or  any  other  variant  will  be  rejected  by  the  system  as  an 
illegal  entry.  Information  on  legal  entries  provides  guidance 
to  the  user/operator  in  determining  the  correct  code  for  the 
data  element  he/she  wants  to  represent. 

c.  The  user's/operator's  entry  can  be  valid  but  still  incorrect. 

EXAMPLE:  In  a  field  artillery  system,  the  user  may  nave 
the  option  to  select  from  a  variety  of  types  of  rounds  (high 
explosive,  armor  piercing,  fragmentation,  smoke,  etc.).  Thus, 
any  one  of  several  entries  would  be  valid  in  response  to  the 
system's  data  entry  prompt  (e.g.,  "ENTER  TYPE  OF  ROUND  — ") , 
even  though  only  one  might  be  appropriate  for  a  particular  sit¬ 
uation.  If  the  user/operator  wants  to  call  for  high  explosive 
rounds,  but  enters  "SM"  (for  smoke)  instead  of  "HE"  (for  high 
explosive) ,  the  system  has  no  way  to  "know"  that  the  entry  is 
an  error.  Information  on  legal  entries  permits  the  user/oper¬ 
ator  to  review  the  available  options  for  the  data  entry  field, 
and  to  select  the  code  that  matches  his/her  intentions. 

d.  The  user/operator  may  have  difficulty  recalling  valid  codes 
because  of  inexperience  or  because  the  set  of  codes  is  large. 

EXAMPLE:  In  a  communications  system,  experienced  users/operators 
have  learned  the  codes  to  be  entered  into  each  of  ten  message 
formats.  The  system  must,  however,  be  able  to  operate  even  if 
all  experienced  users/operators  have  become  disabled  or  other¬ 
wise  unavailable.  Information  on  legal  entries  will  permit 
inexperienced  personnel  to  continue  system  operations,  even 
if  with  reduced  efficiency. 

EXAMPLE:  In  an  administration  system,  the  user/operator  must 
enter  a  code  to  denote  a  particular  type  of  medical  supply.  The 
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set  of  such  codes  is  large,  numbering  into  the  thousands.  Even 
highly  experienced  users/operators  cannot  remember  all  the  codes 
and  the  medical  item  that  each  code  represents.  Information  on 
legal  entries  assists  the  user/operator  in  selecting  the  code 
appropriate  to  a  particular  data  item. 

The  codes  or  terminology  used  in  the  system  differ  from  cor¬ 


responding  standard  codes  used  in  most  other  situations 


EXAMPLE:  In  a  command  and  control  system,  the  phrase  "Free  Fire 
Area"  is  coded  as  "FCA, "  rather  than  the  doctrinal  "FFA”  as 
specified  in  FM6-20.  Information  on  legal  entries  alerts  the 
user/operator  to  the  existence  of  such  non-standard  usages. 

The  range  of  values  for  a  numerical  data  field  is  limited. 


EXAMPLE:  In  an  intelligence  information  system,  the  user/oper 
ator  must  enter  latitudes  in  degrees.  Entering  the  value  "97" 
exceeds  the  legal  limit  for  a  latitude.  Information  on  legal 
entries  shows  the  user /operator  the  range  of  legal  values. 

Each  of  the  possible  codes  is  lengthy. 


EXAMPLE:  In  a  command  and  control  system,  the  user/operator 
must  enter  a  unit  ID  for  companies  which  includes  all  of  the 
unit's  parent  organizations  up  to  division  (for  example,  C 
Company,  1st  of  the  64th  Armor,  2nd  Brigade,  14th  Armored 
Division  must  be  entered  as  14/2/1/64/C) .  Information  on 
legal  entries  helps  the  user/operator  to  enter  the  required 
data. 


3.1.4  METHODS  FOR  PRESENTING  INFORMATION  ON  LEGAL  ENTRIES 


a.  Input  menus.  Two  types  of  input  menus  can  be  used  to  show  the 
user/operator  the  legal  entries  for  a  data  field,  simple  and 
hierarchical: 


1.  Simple  input  menus  are  used  when  the  number  of  legal 
entries  is  small  enough  to  require  no  more  them  two 
columns  on  the  display  screen. 


r  AVAILABLE  AMMUNITION  TYPES  ARE:  ^ 


1. 

ARM  — 

ARMOR  PIERCING 

2. 

BIO  — 

BIOLOGICAL 

3. 

ILL  — 

ILLUMINATION  (FLARE) 

4. 

FRA  — 

FRAGMENTATION 

5. 

GAS 

GAS/CHEMICAL 

6. 

INC  — 

INCENDIARY 

7. 

NUC  — 

NUCLEAR 

8. 

SMO  — 

SMOKE 

ENTER  THE  #  OR  LETTER  CODE  FOR  DESIRED  AMMUNITION  TYPE,  OR 
ENTER  ONLY  A  CARRIAGE  RETURN  TO  GET  BACK  — > 


Hierarchical  input  menus  are  used  when  the  number  of  legal 
entries  exceeds  two  columns  on  the  display  screen. 


IN  WHAT  TYPE  OF  EQUIPMENT  ARE  YOU  INTERESTED? 

1.  CO  —  COMBAT  EQUIPMENT 

2.  AI  —  AIR  EQUIPMENT 

3.  TR  —  TRANSPORTATION  EQUIPMENT 

4.  EN  —  ENGINEERING  EQUIPMENT 

5.  etc. 


— >  CO 


IN  WHAT  TYPE  OF  COMBAT  EQUIPMENT  ARE  YOU  INTERESTED? 

1 .  ARM  —  ARMORED  EQUIPMENT 

2.  CMD  —  COMMAND  AND  CONTROL  EQUIPMENT 


1. 

ARM 

2. 

CMD 

3. 

INF 

4. 

etc. 

~>  ARM 


Depending  on  the  user's/operator's  purposes,  an  additional 
frame  could  list  specific  pieces  of  armored  equipment,  or 
the  user/operator  might  request  a  summary  of  available 
armored  equipment  or  request  some  other  processing  func- 
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b.  Input  examples.  Input  examples  are  used  to  show  the  user/ 
operator  the  correct  format  of  legal  entries,  the  correct 
content  of  legal  entries,  or  both. 


ENTER  TIME  IN  HOURS,  MINUTES,  SECONDS  AS  "HH:MM:SS" 


— > 


V. 

r 


ENTER  TIME  IN  HOURS,  MINUTES,  AND  SECONDS  AS  "HH:MM:SS" 


EXAMPLE:  12  SECONDS  AFTER  1  :32  PM 
— >  13:32:12 


Code  books  and  manuals.  Code  books  and  manuals  provide 
detailed  information  on  legal  entries  which  cannot  be 
placed  on  data  entry  displays. 
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3.1.5  RECOMMENDATIONS  ON  INFORMATION  ON  LEGAL  ENTRIES 

a 


Table  3.1-1  presents  general  recommendations  for  using  different 
methods  for  presenting  information  on  legal  entries  depending  on 
the  particular  application.  Before  dec  ding  to  use  one  or  more 
of  these  recommendations,  the  reader  should  review  the  general 
recommendations  in  this  section  and  the  advisory  comments  on 
specific  methods  in  Section  3.1.6. 


Table  3.1-1  Method  of  Presenting  Information  on  Legal  Entries  by 
Application  Being  Considered 
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Use  the  usetr/operator  terminal  to  provide  infosnation  on 
legal  entries  whenever  |>ossible- 
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b.  Use  the  user/operator  terminal  to  provide  information  on 
legal  entries  whenever  possible. 

c.  Use  the  highest  computer-to-terminal  data  transmission 
rates  possible  for  displaying  information  on  legal  entries 

to  the  user/operator  terminal .  Minimum  data  transmission  * 

recommendations  are  presented  in  Table  3.1-2. 


Table  3.1-2.  Minimum  Data  Transmission  Rates  for  Various  Types 
of  Legal  Data  Entry  Information  and  Desired  Dis¬ 
play  Times. 


DESIRED  DISPLAY  TIME 

FAST 

MODERATE 

SLOWEST 

ACCEPTABLE 

Type  of  Legal  Data  Entry 
Information 

Approximate  Number 
of  Characters 

put  Data  on 
Screen) 

put  Informa¬ 
tion  on  Screen) 

put  Informa¬ 
tion  on  Screen) 

Format  for  a  Data  Entry 
Cod* 

1* 

IB  characters 
per  second 
(about  IBB  baud) 

2  characters  per 
second  (about  2f 
baud) 

B.7  characters 
per  second 
(about  7  baud) 

Format  and  Example  for 

Data  Entry  Code 

50 

50  characters 
per  second 
(about  5BB  baud) 

IB  characters 
per  second 
(about  IBB  baud) 

3  characters 
per  second 
(about  30  baud) 

Short  Data  Entry  Menu 
(About  4-8  Options  in 

HP's) 

m 

2M  characters 
per  second 
(about  2000  baud) 

4B  characters 
pe-  second 
(about  4BB  baud) 

13  characters 
per  second 
(about  130  baud) 

Long  Data  Entry  Menu; 
Single  Page  of  Multi- 
Page  Data  Element 
Dictionary  or  Help  File 

IBM 

1BBB  characters 
per  second 
(about  1 B.BBB 
baud) 

ZBB  characters 
per  second 
(about  2000  baud) 

67  characters 
per  second 
(about  670  baud) 

d.  Provide  a  means  for  the  user/operator  to  prevent  the  system 
from  displaying  legal  data  entry  information  if  he/she  is 
experienced  enough  not  to  need  it.  (NOTE:  this  is  partic¬ 
ularly  important  if  data  transmission  rates  to  the  user/ 
operator  terminal  are  low. ) 

e.  Make  display  formats  for  data  entry  identical  to  or  com¬ 
patible  with  formats  used  for  output,  scanning,  and  review 
of  data  items  entered  previously. 

f.  Provide  illustrations  and  examples  for  legal  data  entry 
information  whenever  possible. 

g.  Provide  definitions  for  all  data  entry  codes. 

h.  Order  the  information  on  legal  entries  in  a  manner  which 
is  consistent  with  the  way  in  which  the  user  operator  will 
use  the  information.  Some  examples  of  ordering  methods  are: 


£ 

l 


vv  v-v. 
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alphabetically  (e.g.,  codes  for  designating  countries); 

(2)  SUBJECT  ORDERING,  in  which  codes  are  arranged  by  the 
subject  with  which  they  deal  (e.g.,  codes  for  types  of 
combat  equipment) . 

i.  Message  formats  are  best  designated  by  the  use  of  all  letter 
codes  as  opposed  to  a  mixed  alphanumeric  code. 

j .  Always  provide  legal  entries  in  codebooks  or  manuals  (even 
when  legal  entry  information  is  available  at  user  terminals) , 
for  offline  study  and  reference. 

k.  Provide  duplicate  code  organization  methods  where  different 
users/operators  may  desire  to  locate  codes  in  different  ways. 

l.  Provide  duplicate  legal  entry  information  where  users  may 
use  different  terms  to  mean  the  same  thing,  for  example; 


COUNTRY  NAME 
RUSSIA 


CODE 

URS 


SOVIET  UNION 


UNION  OF  SOVIET  SOCIALIST  REPUBLIC 


URS 

URS 


m.  When  required  data  entries  can  be  deferred,  provide  data  vali¬ 
dation  software  which  signals  omissions  to  the  user/operator, 
permitting  either  immediate  or  delayed  input  of  missing  items. 


|  * 


n.  When  entry  of  a  required  data  item  is  deferred,  require  the 
user/operator  to  enter  a  special  symbol  in  the  data  field  to 
indicate  that  the  item  has  been  temporarily  omitted  rather 
than  ignored. 

o.  Automatically  display  currently  defined  default  values  in 
their  appropriate  data  fields  upon  initiation  of  the  data 
entry  transaction.  Dr  not  expect  the  user  to  remember  them. 

p.  In  any  data  input  transaction,  allow  the  user/operator  to 
replace  a  default  value  with  a  different  entry,  without 
changing  the  current  default  definition. 

q.  When  useful  default  values  for  data  entry  cannot  be  predicted 
by  system  designers,  provide  a  special  transaction  to  define, 
change,  or  remove  default  values  for  each  data  entry  field 

to  the  user/operator  (or  an  authorized  supervisor) . 


8 


r.  When  a  field  delimiter  must  be  used  for  data  entry,  adopt  a 
standard  character  for  that  purpose:  slash  (/)  is  preferred. 
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s.  When  shorter  than  the  maximum  length  of  entry  is  allowed, 
distinguish  between  required  and  optional  elements.  Use  dashes 
( — )  to  denote  required  length;  use  dots  (...)  to  indicate 
additional  elements. 

t.  In  labeling  data  entry  fields,  use  terms,  codes,  and/or  abbre¬ 
viations  that  appear  in  doctrinal  literature  or  that  are  known 
to  be  familiar  to  the  user/operator  population.  (See  6.2, 
Standard  Terms,  and  6.4,  Abbreviations  and  Codes.) 
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3.1.6  ADVISORY  COMMENTS  ON  METHODS  FOR  INFORMATION  ON  LEGAL  ENTRIES 

a.  Input  menus 

Use  information  on  legal  entries  on  input  menus  where  the 
users/operators  of  the  system  are  likely  to  be  inexperi¬ 
enced  in  the  content  of  legal  entries. 

Use  information  on  legal  entries  on  input  menus  where 
input  codes  are  long,  only  if  the  user/operator  can  bene¬ 
fit  from  positional  coding  in  the  menu. 

Provide  a  method  for  experienced  users/operators  to  stack 
commands  to  bypass  input  menus. 

Do  not  use  menus  of  legal  entries  where  data  transmission 
rates  are  low  (below  1200  baud) . 

b.  Input  examples 

When  possible,  use  format  and  content  examples  in  combination 
rather  than  using  one  or  the  other.  (A  content  example  illus¬ 
trates  the  format;  a  format  example  makes  the  format  more 
explicit. } 

c.  User-definable  data  entry  codes 

1.  Use  user-definable  data  entry  codes  where  different  users 
are  likely  to  use  different  sets  of  data  entry  codes. 

2.  Use  user-definable  data  entry  codes  where  users/operators 
will  use  some  codes  more  frequently  than  others. 

d.  Display  linkages 

Use  display  linkages  where  low  computer  storage  capacity 
limits  the  amount  of  information  which  can  be  placed  on 
data  entry  display  menus  and/or  in  HELP  files. 

e.  Code  books  and  manuals 

1.  Always  provide  legal  entries  in  code  books  (even  when 
legal  entry  information  is  available  at  the  user  ter¬ 
minal)  ,  for  off-line  reference  and  study. 

2.  Order  the  information  on  legal  entries  in  a  manner  which 
is  consistent  with  the  way  in  which  the  user/operator 
will  use  the  information.  Some  oxamples  of  ordering 
methods  are: 


1. 

2. 

3. 

4. 


(a)  ALPtfAUETICAL  ORDERING,  in  which  codes  are  arranged 

alphabetically  (e.g.,  codes  for  designating  countries) 
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(b)  SUBJECT  ORDERING,  in  which  codes  are  arranged  by  the 
subject  with  which  they  deal  (e.g.,  codes  for  types 
of  combat  equipment) . 

(c)  DISPLAY  ORDERING,  in  which  codes  are  arranged  so  that 
valid  codes  for  a  particular  display  are  all  in  a 
single  place  in  the  code  book  or  manual. 

Provide  duplicate  code  organization  methods  where  different 
users/operators  may  desire  to  locate  codes  in  different 
ways. 

Provide  duplicate  legal  entry  information  where  users  may 
use  different  terms  to  mean  the  same  thing.  For  example: 


COUNTRY  NAME  CODE 

RUSSIA  URS 

•  • 

•  • 

SOVIET  UNION  URS 

•  • 

UNION  OF  SOVIET  SOCIALIST  REPUBLICS  URS 


3.2  Unburdening  of  Input 


3.2.1  DEFINITION 


Unburdening  of  input  deals  with  ways  to  reduce  the  time  anti  effort  required 
to  enter  data  and  commands.  It  consists  of  capabilities  within  the  system  to 


eliminate  or  automate  as  many  input  tasks  as  possible,  thereby  minimizing  the 
workload  for  users/operators. 
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3.2.2  APPLICATIONS  FOR  UNBUROENING  OF  INPUT 


a.  In  command  entry,  when  lengthy  commands  are  typed  in  at  the 
keyboard. 

EXAMPLE:  A  tactical  intelligence  system  uses  commands  such  as 
PRINT,  READ,  EXECUTE,  and  TRANSFER  to  control  the  sequence  of 
operations  and  the  flow  of  data  in  the  system.  Forcing  the 
user/operator  to  type  in  each  command  in  its  entirety,  rather 
than  permitting  entry  of  abbreviations  (e.g.,  Print,  Read, 
Execute,  Transfer) ,  imposes  an  unnecessary  burden  in  terms 
of  the  numbers  of  required  keystrokes.  The  excess  keystrokes 
also  provide  unnecessary  opportunities  for  keying  errors. 

b.  In  repetitive  command  sequences. 

EXAMPLE:  An  administrative  system  uses  commands  to  identify 
the  type  of  personnel  transaction  being  entered  (e.g.,  PROMO¬ 
TION,  PCS,  LEAVE) .  Forcing  the  user/operator  to  enter  the 
same  command  each  time  a  particular  transaction  type  is 
entered  imposes  an  unnecessary  burden,  and  creates  additional 
opportunities  for  keying  errors. 

c.  When  the  system  has  a  large  command  set. 

EXAMPLE:  A  supply  control  system  has  a  large  number  of 
commands  to  control  the  various  types  of  data  entries  and 
routine  output  reports.  Forcing  the  user/operator  to  learn 
this  command  set  in  order  to  accomplish  normal  operations 
imposes  an  excessive  memory  burden. 

d.  In  highly  repetitive  data  entry  tasks. 

EXAMPLE:  A  command  and  control  system  requires  certain  types 
of  data  that  do  not  change  frequently  over  time  (e.g.,  unit 
identifications) ,  but  which  appear  in  most  or  all  input  and 
output  formats.  Forcing  the  user/operator  to  enter  this 
relatively  constant  data  each  time  such  a  format  is  used 
imposes  an  unnecessary  burden. 

e.  In  entry  of  lengthy  data  items. 

EXAMPLE:  To  obtain  the  required  accuracy  in  target  coordinates, 
an  artillery  system  requires  the  user/operator  to  enter  10-digit 
values  for  the  target's  latitude  and  longitude.  Entering  each 
value  as  a  continuous  10-digit  string  imposes  an  excessive 
short-term  memory  burden. 

f .  In  transcribing  data  from  typed  or  printed  forms. 

EXAMPLE:  A  supply  system  requires  the  user/operator  to  type 
in  data  from  standard  printed  forms.  If  the  input  format  does 
not  match  the  format  of  the  printed  form,  the  user/operator  must 
search  through  the  form  for  each  data  item,  making  the  entry 
task  unnecessarily  complex. 


When  only  a  few  data  fields  must  be  entered  into  a  preformatted 
display  containing  many  fields. 


EXAMPLE:  An  artillery  command  and  control  system  uses  prefor¬ 
matted  displays  for  all  data  input.  Often,  only  two  or  three 
of  the  data  fields  must  be  used  to  provide  the  required  entry. 
Forcing  the  user/operator  to  skip  over  unneeded  fields  reduces 
throughput  and  increases  the  probability  of  entering  data  in 
inappropriate  fields. 


h.  When  data  to  be  entered  are  received  in  nonstandard  order. 

EXAMPLE:  In  a  personnel  system,  the  user/operator  usually 
receives  data  on  printed  forms.  Occasionally,  however,  data 
are  received  in  unstructured,  verbal  communications.  Forcing 
the  user/operator  to  enter  such  data  in  a  standard,  fixed 
sequence  imposes  a  burden  on  both  the  user/operator  and  the 
provider  of  the  data. 


i.  when  varying  formats  describe  the  same  data  content. 

EXAMPLE:  A  date  may  be  expressed  in  a  variety  of  numeric  and 
alphanumeric  forms  (e.g.,  11/30/81  or  30  November  1981). 
Forcing  the  user/operator  to  use  only  one  fixed  form  requires 
an  unnecessary  translation  of  all  other  forms  to  the  required 
form. 


j •  When  data  may  be  expressed  in  more  than  one  unit  of  measurement 

EXAMPLE:  An  artillery  command  and  control  system  uses  latitude 
and  longitude  for  target  coordinates  and  other  location  infor¬ 
mation.  Forcing  the  user/operator  to  translate  other  measure¬ 
ment  units  (e.g.,  UTM)  to  latitude  and  longitude  will  reduce 
throughput  and  increase  errors. 


3.2.3  8ENEFITS  OF  UNBURDENING  OF  INPUT 


Unburdening  of  input  will  enhance  overall  system  performance  through 
improved  user/operator  performance  by : 

a.  Reducing  error  rates,  by  minimizing: 

1.  Inability  of  the  user/operator  to  maintain  throughput 
requirements  given  the  amount  of  command  or  data  entry 
keystrokes  necessary. 

2.  Probability  of  typographical  error  for  each  keystroke. 

3.  Judgmental  or  logical  errors  in  defining  complex  sequences 
in  commands  which  could  have  been  "canned"  by  the  users/ 
operators  in  previous  executions  of  the  same  command 
sequence. 

4.  Probability  of  selecting  commands  or  data  entry  options 
which  are  invalid  given  prior  user/operator  command  or 
data  entries. 

5.  Transcription  errors  in  data  or  command  input  which  could 
have  been  generated  or  obtained  by  the  computer  system. 

6.  Increased  error  rate  associated  with  entry  of  redundant 
information  for  purposes  other  than  verification  and 
validation. 

7.  Misestimations  from  graphics  displays. 

8.  Failure  to  accurately  recall  command  or  data  entry  content/ 
format  presented  on  non-linked  HELP  displays. 

b.  Increasing  system  throughput  rates,  by  minimizing: 

1.  Time  required  for  entry  of  individual  commands  which 
require  more  keystrokes  than  necessary. 

2.  Time  required  to  generate  commands  which  could  have 
been  stored  for  subsequent  use. 

3.  Time  required  to  enter  redundant  commands  in  situations 
other  than  verification  and  validation  processes. 

4.  Time  required  to  correct  errors  resulting  from  inade¬ 
quate  attention  to  considerations  of  unburdening  of 
input. 
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3.2.4  METHODS  FOR  UNBURDENING  OF  INPUT 


a.  Computer-propagated  data.  If  a  data  item  does  not  change  often 
but  is  used  frequently  by  the  system  (e.g.,  a  unit  identifier), 
it  can  be  saved  in  a  special  area  of  storage  and  then  retrieved 
automatically  whenever  needed. 

b.  Computer-generated  data.  When  necessary  data  can  be  calculated 
from  data  entered  previously,  the  machine  can  perform  the  cal¬ 
culations  automatically  and  display  the  result  when  and  where 
needed. 

c.  Hardware  form  scan.  If  typed  or  printed  forms  are  prepared  in 
a  machine-readable  font,  hardware  scanners  can  be  used  to  input 
the  data  into  the  system. 

d.  Menus .  Menus  can  be  used  to  ease  the  burden  on  users/operators, 
both  for  entering  commands  and  for  entering  data. 
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AVAILABLE  AMMUNITION  TYPES  ARE: 

I. 

ARM  - 

ARMOR  PIERCING 

2. 

BIO  - 

BIOLOGICAL 

3. 

ILL  - 

ILLUMINATION  (FLARE) 

4. 

FRA  - 

FRAGMENTATION 

5. 

GAS  - 

GAS/CHEMICAL 

6. 

INC  - 

INCENDIARY 

7. 

NUC  - 

NUCLEAR 

3. 

SMO  — 

SMOKE 

ENTER  THE  §  OR  LETTER  CODE  FOR  DESIRED  AMMUNITION  TYPE,  OR 

ENTER  ONLY  A  CARRIAGE  RETURN  TO  GET  BACK  — >  J 

l -  J 

HEXiP  files.  HELP  files  can  be  used  to  explain  the  format, 
structure,  and  required  content  of  lengthy  data  items.  They 
can  be  used  in  similar  fashion  for  large  command  sets. 


UNIT  I.D.  CONSISTS  OF  THE  FOLLOWING  ITEMS  OF  INFORMATION: 

1 .  COMPANY 

2.  BATTALION 

3.  BRIGADE 

4.  DIVISION 

ENTER  THESE  ITEMS  IN  THE  SAME  ORDER  AS  LISTED  ABOVE. 
SEPARATE  EACH  ITEM  FROM  THE  NEXT  ITEM  WITH  A  SLASH. 

FOR  EXAMPLE,  8  CQHPANY  OF  THE  1st  OF  THE  64th  AR 
BATTALION,  3rd  BRIGADE,  37  AR  DIVISION  WOULD  BE: 

3/1 -64  AR/3/37  AR 

ENTER  YOUR  UNIT  I.D.-.b 


Prespecification  of  data  entry  progression.  Software  can  be 
provided  to  permit  the  user  to  specify  the  sequence  in  which 
data  items  will  be  entered. 


THE  "UNIT  DATA"  FORMAT  CONTAINS  THE  FOLLOWING  DATA  ITEMS: 


1. 

UNIT  I.D. 

6. 

MORALE 

2. 

DTG 

7. 

TRANSPORT 

3. 

CDR 

8. 

READINESS 

4. 

PARENT  UNIT 

9. 

WEAPONS 

5. 

PERSONNEL  STRENGTH 

10. 

AMMUNITION 

ENTER  THE  NUMBERS  OF  THE  DATA  ITEMS  YOU  WANT  TO  USE,  IN 
THE  ORDER  YOU  WANT  TO  USE  THEM.  USE  COMMAS  TO  SEPARATE 
THE  NUMBERS.  FOR  EXAMPLE: 

1,  4,  7,  10,  5 


Fixed  function  keys.  Fixed  function  keys  allow  the  user/operator 
to  press  a  special  key  on  a  terminal  keyboard  to  indicate  to  the 
computer  that  a  particular  operation  should  be  performed.  The 
keys  are  labeled  with  the  operations  which  the  system  is  to  per- 
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Variable  function  keys.  The  user/operator  presses  a  special 
key  to  indicate  to  the  computer  that  a  particular  operation 
should  be  performed.  The  variable  function  key  may  perform 
different  functions,  depending  on  what  kind  of  activity  the 
user/operator  is  performing.  Usually  the  specific  effect  of 
pressing  a  given  variable  function  key  is  indicated  by  a 
brief  menu  presented  on  the  terminal  or  on  transparent  key 
label  overlays  or  underlays. 


KEY  1:  STORE  KEY  2:  RETRIEVE  KEY  3:  EDIT 
KEY  k:  XMIT  KEY  5:  VIEW  QUEUE 


[ 


STORE 
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Cursor  control  for  field  specification.  The  user/operator  moves 
the  cursor  to  the  first  data  entry  position  of  the  desired  data 
field.  The  system  recognizes  the  cursor  position  and  acknowledges 
that  the  data  field  has  been  selected. 


USER  CODE  NUWER: _ _ ID  NUMBER: 

CHARCE  CODE: _ OATA  FI  IE  DESIRED:  (  _ 

ACTIVITY:  STORAGE RETRIEVAL :_  £DITIHG:_ 

OPTIONS: 


HARD  COPY  DESIRED?  (Y/N):.. 


ENTER  DATA  FILE  DESIRED 


J 


Graphics  tablet  for  field  specification.  The  user/operator  uses 
the  stylus  of  a  graphics  tablet  to  indicate  the  desired  data 
field.  The  system  recognizes  the  stylus  input,  positions  the 
screen  cursor  to  the  first  entry  position  of  the  data  field, 
and  acknowledges  that  the  data  field  has  been  selected  (as 
shown  immediately  above) . 

Touch  screen  for  field  specification^  This  method  is  analogous  to 
“i*'and”“j above',  except  that  the  user/operator  touches  the  face 
of  the  display  screen  to  indicate  the  desired  data  field. 
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CODE 


STANDS  FOR 


3H 

303_FA_BD_HQ 

4S 

404  FA  BD  SD 

ENTER  UNIT  DESIGNATION  ~>  3Q3_FA_8D_HQ 
(VALID  ENTRY  CODE) 


r  ■  "  -  ■ 

ENTER  UNIT  DESIGNATION  — >  3H  (VALID  ENTRY 
CODE) 


On-screen  form  analogs.  The  pre formatted  input  display  provides 
a  "fill  in  the  blanks"  approach,  using  the  same  format  as  a  cor¬ 
responding  printed  form. 

Machine  transgeneration.  The  machine  incorporates  software  to 
translate  a  data  entry  in  one  unit  of  measurement  to  some  other 
unit  of  measurement.  For  example,  location  data  entered  as 
■latitude-longitude  could  be  translated  automatically  to  UTM. 

Format  recognition.  In  many  situations,  the  machine  can  recog¬ 
nize  data  on  the  basis  of  its  format.  For  example,  when  asking 
for  a  date,  the  forms  "January  21  1981"  and  "21  Jan  81"  are  suf¬ 
ficiently  distinctive  that  the  machine  can  interpret  them 
accurately  (and  translate  them  to  another  form  as  necessary) . 

Self -prompted  input.  Software  can  be  provided  to  permit  the 
user/operator  to  type  in  the  name  of  a  function  to  be  performed 
and  the  data  field  labels  and  corresponding  data  items.  This 
capability  provides  an  alternative  to  filling  in  preformatted 
displays.  For  example,  rather  than  calling  up  a  format  and  then 
skipping  past  multiple  unneeded  fields,  a  user/operator  might 
enter: 


/ - - - - N 

RUN  XYZ,  DATE  =  JAN  21  81,  TGI  »  ALPHA, 

AUTH  =  HPY33 


V _ / 


The  system  would  then  execute  function  XYZ,  using  the  data  pro¬ 
vided  and  default  or  previously  entered  values  for  all  data 
fields  not  entered  by  the  usor/operator. 
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3.2.5  RECOMMENDATIONS  ON  UNBURDENING  OF  INPUT 


Table  3.2-1  presents  recommendations  for  using  particular  methods 
for  unburdening  of  input,  depending  on  the  specific  data  entry 
application.  Before  deciding  to  use  one  or  more  of  these  methods, 
the  reader  should  review  the  general  recommendations  that  follow, 
and  consult  the  advisory  comments  on  specific  methods  contained 
in  Section  3.2.6. 


Table  3.2-1.  Method  of  Unburdening  of  Input  by  Type  of  Data 
Entry  Applications 


for  lU«6)n3U4l<0«  jwr^o «t. 
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b.  Standardize  data  entry  procedures  to  the  maximum  extent 
feasible.  Make  formats,  data  item  locations,  grammatical 
structures,  and  input  modes  as  consistent  as  possible  through¬ 
out  the  system's  functions  and  workstations. 

c.  Any  time  the  user/operator  presses  any  key,  project  the 
character  or  label  associated  with  that  key  on  the  display. 
Exceptions : 

1.  Each  character  of  a  password  or  other  system  security 
item  may  be  replaced  with  a  standard  character— pref¬ 
erably  "x." 

2.  When  cursor  control  keys  are  pressed,  the  corresponding 
movement  of  the  cursor  eliminates  the  necessity  for  a 
symbol  to  appear  on  the  display. 

d.  In  systems  employing  typed-in  commands,  allow  the  user/operator 
the  option  to  enter  a  series  of  commands  as  a  single  string. 
Separate  individual  commands  in  the  string  by  a  standard 
delimiter — preferably  the  virgule  (/) . 

e.  When  a  command  or  data  string  has  been  entered,  and  the  system 
finds  missing  or  incorrect  items  in  the  string,  do  not  require 
the  user/operator  to  re-enter  the  entire  string..  Provide  soft¬ 
ware  to  prompt  only  for  the  missing  or  incorrect  portion  of  the 
string. 

f.  Do  not  require  the  user/operator  to  remember  data  entered  on 
previous  display  frames.  If  previously-entered  data  is  nec¬ 
essary,  present  the  needed  data  as  part  of  the  current  frame. 

g.  Do  not  develop  data  entry  situations  that  force  the  user/opera¬ 
tor  to  switch  frequently  from  one  input  mode  to  another  (e.g., 
switch  back  and  forth  between  light  pen  to  keyboard) .  To  the 
maximum  extent  possible,  allow  the  user/operator  to  remain 
with  one  input  mode  throughout  a  transaction. 

h.  When  a  user's/operator's  workstation  incorporates  more  than 
one  display  device  (e.g.,  multiple  CRT  screens),  allow  the 
user /opera tor  to  use  the  primary  display  for  data  entry. 

i.  To  the  maximum  extent  possible,  allow  the  user/operator  to 
enter  data  at  his/her  own  pace. 

j.  After  the  user/operator  has  completed  a  data  entry  task,  pro¬ 
vide  the  option  to  review  and  verify  the  complete  set  of 
newly-entered  data. 
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When  the  data  to  be  entered  are  alphabetic,  do  not  restrict 
the  alphabetic  character  set  (e.g.,  do  not  prohibit  the  use 
of  "Q"  and  "Z"). 

Always  require  the  user/operator  to  take  an  explicit  action 
to  enter  a  command  or  data  string.  An  ENTER  key  is  appro¬ 
priate  for  this  purpose.  Do  not  allow  an  unrealted  action 
(such  as  returning  to  a  menu  of  control  options)  to  signify 
entry  of  data  just  keyed  into  a  display. 

When  a  key  is  used  to  explicitly  indicate  that  just-keyed 
data  are  to  be  accepted  by  the  computer  for  checking  and/or 
processing,  label  the  key  ENTER.  Do  not  label  this  key  CR, 
RETURN,  or  XMIT. 

To  the  maximum  extent  possible,  keep  the  length  of  individual 
data  items  to  7  characters  or  less.  This  avoids  excessive 
burden  on  the  user's/operator's  memory.  Exception:  text 
material . 

If  individual  numerical  data  items  must  be  longer  than  7 
characters,  allow  the  user/operator  to  enter  the  item  in 
groups  of  three  or  four  digits. 

Do  not  force  the  user/operator  to  enter  leading  zeros,  lead¬ 
ing  blanks,  or  other  characters  merely  for  formatting  purposes 
Provide  software  to  accomplish  right  or  left  justification 
and  decimal  point  alignment  of  tabular  data  entries. 

In  tabular  data  formats,  left  justify  column  headings, 
especially  if  data  items  in  the  column  vary  in  length. 

Locate  input  prompts  in  a  consistent  screen  location,  pref¬ 
erably  in  the  bottom  quarter  of  the  screen. 

Use  the  colon  (:)  to  denote  a  prompt  (e.g.,  ENTER  NAME: _ ), 

On  the  display  screen,  use  the  colon  only  for  this  purpose. 
Exception:  extended  text. 

For  input  prompts,  indicate  the  maximum  number  of  characters 
permitted,  the  spacing,  and  the  syntax.  Example: 


Use  a  separate  prompt  for  each  data  item: 


- > 

USER  ID: _ 

TERMINAL  ID: _ / _ /_  _ 

PASSWORD: _ - _ 

V _ _ 


Do  not  combine  prompts  for  multiple  data  items: 


f  ENTER  USER  ID,  TERMINAL  ID.  AND  PASSWORD:  ^ 


___/ _ /__ 

L__i_ _ _ _ / 


If  the  user/operator  must  interact  witn  a  network  of  systems, 
provide  software  to  translate  one  system's  data  formats  and 
structures  to  another's.  Do  not  force  the  user/operator  to 
perform  such  translation  tasks. 

Whenever  possible,  use  source  data  entry,  i.e.,  enter 
directly  from  incoming  messages,  rather  than  recording 
the  data  on  paper  forms  and  then  transcribing  from  the 
forms  into  the  system. 

Design  each  input  display  frame  for  a  specific  task  or  sub¬ 
task.  Then  present  on  that  frame  only  the  information 
actually  required  for  that  input  task  or  subtask.  Do  not 
provide  "contextual"  or  "supplemental"  information  that  is 
not  actually  needed. 

Do  not  "pack"  an  input  display  frame  with  data  items,  merely 
to  reduce  the  number  of  frames  required  for  a  unit  of  work. 

Provide  a  capability  to  require  the  user/operator  to  confirm 
entries  of  critical  commands  or  data.  For  example: 

— 

YOU  ENTEREO  "OELETE  WAR. DAT* 

EXECUTION  OF  THIS  COWAND  WILL  DELETE  THE  WHOLE  FILE 
NAMED  MRS. OAT 

I.  PRESS  CONFIRM  TO  EXECUTE  THE  COMMAND  TO 
DELETE  WRO.OAT 

t.  PRESS  ENTER  (or  ioae  oLNer  Aty)  TO  CANCEL  THE 
COWANO  TO  DELETE  VRC.DAT 
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bb.  When  the  user/operator  is  required  to  confirm  entry  of  multiple 
commands  or  multiple  data  entries,  ensure  that  the  confirming 
action  results  in  entry  of  all  the  items  regardless  of  the 
cursor's  location  on  the  screen  at  the  time  confirmation  is 
made . 

cc.  Do  not  permit  deletion  of  data  items  by  direct  command  entries 
without  first  displaying  the  value  to  be  deleted. 

dd.  Do  not  permit  changes  to  data  items  by  direct  command  entry 
without  first  displaying  the  value  to  be  deleted. 

ee.  Except  for  text,  accomplish  data  entry  and  changes  by  direct 

replacement  of  characters.  Use  keyed  inputs  to  replace  under¬ 
scores  or  previous  entries  (including  default  values)  in  data 
fields. 

ff.  when  possible,  choose  special  characters  used  in  data  entry 

(@,  *,  +,  #,  etc.)  so  that  the  user/operator  will  not  have  to 
shift  between  upper  case  and  lower  case  on  the  keyboard. 

gg.  In  repetitive  data  entry  tasks,  perform  data  validation  for 

each  transaction  and  allow  the  user/operator  to  correct  errors 
before  beginning  the  next  transaction. 

hh.  In  multiple-entry  transactions  provide  item-by-item  error  check¬ 
ing  and  validation  only  as  an  option  selectable  by  the  user/ 
operator. 

ii.  Allow  the  user/operator  to  accomplish  acceptance  of  default 
values  by  a  simple  action,  such  as  by  pressing  a  CONFIRM  or 
TAB  key. 

jj.  whe.i  a  user/operator  edits  or  updates  a  data  item  that  is 

stored  in  more  than  one  file,  provide  automatic  updating  of 
each  file  containing  that  item.  Exception:  history  *iles. 
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kk.  Any  time  the  user/operator  enters  multiple  data  items  in  a 
single  transaction,  provide  the  options  to  RESTART,  CANCEL, 
or  BACKUP  to  change  any  item  before  taking  a  final  ENTER 
action. 

11.  When  a  delimiter  is  needed  to  separate  the  subfields  of  a 
data  item,  use  the  virgule  {/) .  Exceptions:  well-known 
items  such  as  telephone  numbers  (e.g.,  (703)  385-0190)  and 
social  security  numbers  (e.g.,  374-36-9267). 

mm.  When  a  dimensional  unit  (e.g.,  $,  mph,  km,  gal)  is  consistently 
associated  with  a  particular  data  field,  display  it  as  part 

of  the  data  field  label  (e.g.,  FUEL: _ GAL).  Do 

not  require  the  user/operator  to  enter  it  each  time  the  data 
item  is  entered. 

nn.  When  alternative  dimensional  units  are  acceptable  (e.g.,  mph, 
kph) ,  provide  space  in  the  data  field  for  the  unit  descriptor. 

oo.  Design  input  formats  to  be  identical  or  compatible  to  corre¬ 
sponding  output  formats. 

pp.  When  user/operator-computer  dialogs  involve  prompting,  prompt 
data  entries  explicity  by  displaying  data  field  labels  and/or 
associated  user/operator  guidance  messages. 

qq.  When  some  entries  in  a  multiple  entry  transaction  are  optional, 
arrange  the  optional  items  after  the  mandatory  items.  Indicate 
OPTIONAL  in  the  prompts  for  optional  items.  For  example: 


rr.  Provide  multiple  paths  through  a  transaction,  to  accommodate 
experienced  as  well  as  inexperienced  users/operators.  For 
example,  in  a  menu-oriented  system,  allow  inexperienced 
individuals  to  work  through  a  sequence  one  menu  at  a  time. 
However,  provide  the  capability  for  experienced  users/oper¬ 
ators  to  enter  a  conmand  stack  and  bypass  the  menu  sequence. 


j 
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ss.  When  useful  default  values  cannot  be  predicted  in  advance, 
provide  a  capability  for  authorized  personnel  to  use  a 
special  transaction  to  define,  change,  or  delete  default 
values  for  each  data  field. 
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Software  protect  areas  of  display  not  used  for  data  entry 
(e.g.,  data  field  labels,  blank  spaces  used  for  formatting 
purposes)  to  prevent  inadvertent  character  entry  into  such 
areas . 

Make  the  predefined  cursor  HOME  position  consistent  for  all 
display  frames. 

Do  not  require  the  user/operator  to  re-enter  data  items  that 
have  not  changed  since  the  last  transaction.  Also  do  not 
require  the  user/operator  to  enter  data  items  already  avail¬ 
able  to  the  computer  (e.g.,  the  current  time  or  date). 


1.  when  the  computer  inserts  data  into  a  field  from  a 
previous  entry  or  from  already  available  sources  (e.g., 
the  system  clock) ,  display  the  data  as  a  default  value. 

2.  Automatically  skip  the  cursor  past  data  fields  filled 
by  computer-propagated  data. 

3.  If  the  user/operator  is  permitted  to  alter  the  contents 
of  data  fields  automatically  filled  by  computer-propa¬ 
gated  data,  provide  a  TAB  BACK  function  key.  Pressing 
this  key  would  move  the  cursor  backward  to  the  first 
character  entry  position  of  the  previous  data  field. 

Computer-generated  data 

1.  When  the  computer  inserts  data  into  a  field  that  it 
calculates  from  previously  entered  data,  display  the 
calculated  data  as  a  default  value. 

2.  Automatically  skip  the  cursor  past  any  data  field  filled 
by  computer-generated  data. 

3.  Provide  the  capability  for  the  user/operator  to  indicate 
his/her  desire  to  change  a  computer-generated  data  value 
However,  before  permitting  the  value  actually  to  be 
changed,  display  the  basis  for  the  computer  calculations 
For  example,  if  DISTANCE  were  calculated  from  MPH  and 
TRAVEL  TIME,  and  the  user/operator  indicated  a  wish  to 
change  the  value  of  DISTANCE,  the  machine  might  respond: 

r 

DISTANCE  •  MPH  X  TRAVEL  TINE 
75  MILES  *30  X  2.5  HOURS 

IF  YOU  WANT  TO  CHANGE  DISTANCE,  YOU  MUST  ALSO  CHANGE 
HFH  Oft  TRAVEL  TINE.  WHAT  DO  YOU  WANT  TO  00? 

1 .  KEEP  THE  DATA  SHOWN  ABOVE 

2.  CHANGE  NPH  (NACHINE  WILL  CALCULATE  DISTANCE) 

3.  CHANGE  TRAVEL  TIKE  (KACHINt  WILL  CALCULATE 
DISTANCE) 


ENTER  YOUR  CHOICE: ■ 
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Hardware  form  scan 

1.  Make  hardware  form  scanning  a  separate  transaction. 

Do  not  require  the  user/operator  to  leave  an  interactive 
terminal  to  do  form  scanning  during  an  interactive  session 
if  this  can  be  avoided. 


Menus 

1.  If  at  all  possible,  do  not  require  the  user/operator  to 
move  the  cursor  to  a  data  item  in  order  to  select  that 
item  from  a  menu.  Instead,  number  each  item  and  allow 
the  user/operator  to  enter  the  number  of  the  selected 
item.  Also,  provide  the  option  to  enter  codes  composed 
of  the  initial  characters  of  the  options.  For  example: 


THE  AVAILABLE  OPTIONS  ARE: 

1.  (RE)TRIEVE  DATA 

2.  (ST)ORE  DATA 

3.  (ED)IT  DATA 

4.  (AD) D  A  FILE 

5.  (DE)LETE  A  FILE 


ENTER  DESIRED  OPTION  ~> 


2.  If  position  designation  must  be  used  to  indicate  menu 
selection,  use  a  light  pen  rather  than  other  devices 
(c.g.,  cursor  keys,  trackball,  joystick)  to  select  the 
desired  option. 

3.  Provide  a  capability  for  users/operators  to  by-pass  a 
well-known  sequence  of  menus  by  entering  a  single  string 
of  menu  options.  Command  stacks  are  particularly  appro¬ 
priate  for  this  purpose. 

HELP  files 

1.  Provide  a  HELP  file  for  every  transaction.  Bach  HELP  file 
should  contain  an  explanation  of  each  data  field  used  in 
the  transaction,  koyed  to  that  field. 
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:.  Provide  HELP  files  only  as  options  selectable  by  the 
user/operator.  Provide  a  HELP  function  key,  or  allow 
the  user/operator  to  enter  a  special  character  in  the 
data  field  (preferably  "?")  to  select  HELP. 

When  the  user/operator  selects  HELP,  present  only  the 
explanatory  information  appropriate  to  the  particular 
data  field  currently  being  addressed. 

If  at  all  possible,  provide  at  least  two  levels  of  HELP 
information — the  first  level  to  contain  a  brief  reminder 
of  the  purpose  and  required  contents  of  the  data  field, 
the  subsequent  level (s)  to  contain  increasingly  detailed 
information.  In  the  last  level  of  HELP,  advise  the  user/ 
operator  to  seek  guidance  from  a  specific  manual  or  code 
book  or  to  confer  with  a  supervisor  if  the  explanation 
is  not  sufficient  to  remove  his/her  confusion. 

.  Express  HELP  information  in  the  user's/operator's  func¬ 
tional  language  (e.g.,  explain  artillery  data  fields 
in  artillery  language) ,  not  in  the  language  of  computer 
designers,  manufacturers,  or  programmers. 

Prespecification  of  data  entry  progressions 

1.  Allow  the  user/operator  to  describe  the  sequence  of  data 
entries  in  a  table  of  his/her  own  construction.  For 
example; 


INPUT  FORMAT 


USER  CODE  NUMBER: 


!Q  NUMBER: 


CHARGE  COOE: _ QATE  FILE  DESIRED: 

ACTIVITY:  STORAGE;  RETRIEVAL;  EDITING: 


OPTIONS: 


HARD  COPY  OESIREOT  (Y/N):. 
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USER'S/OPERATOR’S  SPECIFICATION  TABLE 

1 .  USER  COOE  NUMBER 

2.  DATA  FILE  DESIRED 

3.  ACTIVITY:  EDITING 

4.  OPTIONS 


J 


In  this  example,  the  user/operator  constructs  the  specifica¬ 
tion  table  using  a  special  transaction  provided  for  this 
purpose.  Then,  when  the  input  format  is  displayed,  the 
system  retrieves  the  specification  table  and  uses  it  to 
position  the  cursor  only  to  those  fields  listed  in  the 
table  (interpreting  item  3  to  mean  that  this  user/operator 
will  only  edit  data) . 

g.  Fixed  function  keys 

1.  Label  fixed  function  keys  accurately  (e.g.»  ENTER,  not 
CR  or  RETURN,  to  signal  the  computer  to  enter  data  input 
to  the  screen) ,  especially  when  user s/operators  are  likely 
to  be  unsophisticated. 

3.  Croup  fixed  function  keys  according  to  purpose  and  type 
of  data. 


VI 


‘V* 


W: 


K 


u 


i 


m 

S  -  a  -  k  *  »  '  *:* 

3  '4  «  *  «  *  *  *,* 


,‘VV,‘V.*V  v  v  • 
v-V 

VV-.-  ■■  .3 


>  _•  ■ 


3.  Provide  fixed  function  keys  for  commands  that  are  entered 
frequently. 

4.  If  fixed  function  keys  are  enabled  at  some  points  in  sys¬ 
tem  operations  and  disabled  at  other  paints,  provide  a 
light  behind  the  key  that  is  on  when  the  func* von  is 
enabled. 

5.  Do  not  Use  fixed  function  keys  if  the  command  se?  is 
larger  than  about  30  commands,  or  if  commands  require 
multiple  parameters. 
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6.  Fixed  function  keys  are  particularly  appropriate  for  simple 
transactions  that  ar.  perforrea  frequently  (e.g.,  NEXT  PAGE, 
PREVIOUS  PAGE ,  HELP,  RE -BOOT  CONTINUE). 

7.  Particularly  when  tabular  formats  art  used,  provide  a  DITTO 
key  when  data  are  duplicated  frequency. 

8.  Display  the  Purpose  of  each  fixed  function  key  at  all  times - 
whether  the  key  is  enabled  or  disabled  at  any  given  point 

in  system  operations.  The  best  method  for  this  is  to  mark 
the  function  xey  directly;  alternatively,  the  label  can  be 
displayed  beside  the  key. 

9.  Use  fixed  function  keys  for  particularly  critical  inputs, 
to  avoid  spelling  or  syntax  errors  and  to  minimize  input 
time. 

10.  Do  not  force  the  user/cperator  to  press  more  than  one  fixed 
function  key  (e.g.,  SHIFT  or  ENABLE  plus  the  function  key) 
to  perform  a  simple  operation.  Exception:  If  unintentional 
activation  of  a  fixed  function  key  would  have  serious  con¬ 
sequences  for  system  <r  tions  or  system  output,  do  require 
the  user/operator  to  p  two  keys  simultaneously  to 
activate  that  function. 

11.  Do  not  assign  different  functions  to  a  tv-ole  fixed  func¬ 
tion  key,  with  the  applicable  function  depending  on  the 

I  articular  point  in  system  operations.  Use  variable  func- 
cion  keys  for  such  purposes.  (See  the  following  section  of 
Advisory  Comments.) 

Variable  function  keys 

1.  When  the  1 unction  of  a  variable  function  key  depends  on 
the  particular  point  in  system  operations,  provide  a  back¬ 
lighted  label  for  each  function  assigned  to  the  key.  Turn 
on  the  light  for  the  currently  available  function,  and  turn 
off  the  light (s)  for  disabled  functions. 

2.  Use  software  to  disable  variable  function  keys  not  needed 
for  current  tasks.  Do  not  provide  mechanical  overlays 
for  this  purpose. 

3.  To  the  maximum  extent  feasible,  place  function  labels  on, 
in,  or  beside  variable  function  keys,  rather  than  listing 
options  on  the  display  screen  and  encoding  the  function  keys 
numerically  or  alphanumerically . 

Cursor  control  for  field  specification 


2.  Use  a  pointing  device  (e.g.,  light  pen)  rather  than  discrete 
or  continuous  devices  (e.g. ,  keys,  trackball,  joystick)  to 
move  the  cursor  to  a  desired  data  field. 

3.  If  input  formats  contain  data  fields  that  are  not  used  for 
every  transaction,  arrange  these  fields  behind  those  that 
are  used  most  frequently. 

4.  Signal  completion  of  a  position  designation  action  by  . 
immediate  feedback  to  the  user,  normally  by  appearance 
of  the  cursor  at  the  first  input  character  position  of 
the  selected  data  field. 

5.  Do  not  use  cursor  control  for  field  specification  by  the 
user/operator  if  other  methods  are  available  (e.g. ,  pre- 
specification  of  data  entry  progressions)  for  sparsely 
filled  forms.  (See  Table  3.2-1.) 

Graphics  tablet  for  field  specification 

1.  The  area  of  a  tablet  reserved  or  specified  as  a  surrogate 
display  screen  must  be  at  least  as  large  as  the  actual 
screen. 

Touch  screen  for  field  specj  fication . 

1.  Touch  screen  for  field  specification  is  not  an  optimal 
method  for  applications  that  require  concurrent  use  of 
other  methods  (e.g.,  keyboard)  to  complete  an  entry.  Use 
touch  screen  methods  when  entries  are  selected  from  menus. 

User-definable  data  entry  codes 

1.  Use  user-definable  data  entry  codes  to  permit  users/ 
operators  to  define  "shorthand"  codes  that  will  reduce 
the  length  of  command  or  data  strings. 

2.  Use  user-definable  data  entry  codes  when  different  users/ 
operators  are  likely  to  use  different  sets  of  data  entry 
codes. 

3.  Use  user-definable  data  entry  codes  when  users/operators 
are  likely  to  use  some  codes  more  frequently  than  others. 

On-screen  form  analogs 


1.  To  the  maximum  extent  possible,  structure  on-screen  form 
analogs  to  resemble  the  typed  or  printed  paper  forms  that 
they  represent.  This  includes  layout  as  well  as  sequence 
of  data  items. 
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Use  implicit  cues  in  on-screen  analogs  to  supplement 
explicit  labels;  use  special  characters  (e.g.,  under 
scores)  to  indicate  field  and  subfield  lengths.  For 
example; 


TIME:  H  M 


Machine  transgeneration 

1.  Use  machine  transgeneration  whenever  data  must  be  converted 
from  one  unit  of  measurement  to  another  (e.g.,  gallons  to 
liters,  kilometers  to  miles). 

Format  recognition 

1.  Use  format  recognition  whenever  different  forms  of  the  same 
data  are  acceptable  to  the  general  population  (e.g., 

Jan  21,  1981;  January  21,  1981?  21  JAN  1981;  21  January  1981? 
1/21/81) . 

2.  When  the  format  of  a  data  entry  is  critical  to  machine  entry, 
provide  formatting  examples  on-line.  For  example; 


■ 

r  - \ 

R 

ENTER  DATE  AS  DDMMYY 

5$ 

EXAMPLE:  21  JAN  1981  WOULD  BE  ENTERED  AS  210181 

ENTER  DATE: 

V 

ft* 

i 

- -  ^ 
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p.  Self -prompted  input 

1.  Use  self-prompted  input  when  only  a  few  data  items  are 
to  be  entered  on  a  form  containing  multiple  items. 

2.  Do  not  restrict  the  sequence  in  which  self-prompted  data 
items  are  entered;  provide  software  to  arrange  the  entered 
items  in  the  order  required  by  the  system. 

q.  Command  macros 


1.  Use  command  macros  when  users/operators  frequently  must 
enter  the  same  sequence  of  commands  (e.g.,  generating  a 
fixed  format  weekly  report) . 

2.  Allow  the  user/operator  to  construct  command  macros  which 
can  query  the  user/operator  for  parameters  whose  values 
change  over  time. 


3.2-27 


) 


3.3  Interrupts  and  Work  Recovery 


3.3.1  DEFINITION 

Interrupts  and  work  recovery  refer  to  operator  activity  halts  which  are 
correctable  through  the  user/operator  interface.  An  activity  halt  may  occur 
when  a  user/operator  is  instructed  by  supervisory  personnel  to  perform  a  dif¬ 
ferent  task  and  must  interrupt  the  current  transaction,  when  hardware  failure 
occurs  or  when  the  user/operator  must  interrupt  current  operations  to  respond 
to  an  incoming  message.  The  user/operator  interface  should  be  designed  to 
provide  assistance  to  the  user/operator  when  original  tasks  are  resumed; 
work  recovery  needs  to  be  immediate  and  unencumbered. 
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3.3.2  APPLICATION  AREAS  FOR  INTERRUPTS  AND  WORK  RECOVERY 

Methods  for  dealing  with  interrupts  and  work  recovery  are  particularly 
appropriate  to  the  following  activities: 

a.  Reacting  to  high-priority  messages  and  tasks. 

EXAMPLE:  A  user/operator  may  receive  an  incoming  message  which 
requires  immediate  attention  or  may  be  assigned  a  task  which  takes 
precedence  over  the  task  at  hand.  As  a  result,  a  halt  in  operator 
activity  occurs. 

b.  Recovery  from  total  system  failure. 

EXAMPLE:  Should  the  external  mobile  power  supply  of  the  van- 
mounted  system  fail,  the  user /opera tor  faces  the  task  of  re¬ 
starting  and  re-initializing  the  entire  system.  Data  items 
in  process  when  the  power  fails  which  include  command  strings 
and  updates  to  the  data  base  will  be  lost  if  they  are  in 
"scratch  pad”  or  volatile  memory. 

c.  Where  system  configuration/reconfiguration  is  required. 

EXAMPLE:  In  a  communication  system,  the  user/operator  prior  to 
conduct  of  a  mission  will  assign  communication  channels  and  hard¬ 
ware  to  link  his/her  system  into  the  communication  network.  Addi¬ 
tionally,  during  conduct  of  a  mission,  terminals  or  items  of 
equipment  may  be  affected  by  hostile  action  or  simple  failure. 

In  this  case,  the  user/operator  will  restore  the  communication 
network  by  reconf iguring  with  either  existing  equipment  or  bring¬ 
ing  standby  units  on-line. 

d.  During  system  and  initialization  startup. 

EXAMPLE:  In  an  artillery  system,  after  the  system  has  been  phys¬ 
ically  relocated  and  devices  powered  up  and  ready  to  be  tested, 
system  startup  and  initialization  are  required.  The  usar/operator 
will  perform  checks  on  his/her  equipment,  run  diagnostics,  and 
use  the  daily  orders  and  look-up  tables  to  assign  peripherals 
and  coamunication  channels  in  order  to  configure  equipment  into 
the  system. 

e.  Upon  messago/communication  receipt. 


EXAMPLE:  while  processing  a  current  task,  the  user/operator  is 
notified  of  the  receipt  of  an  incoming  message.  If  the  user/ 
operator  chooses  to  stop  the  current  task  in  response  to  the 
incoming  message,  the  information  at  hand  will  be  lost,  unless 
recovery  procedures  aro  provided. 
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Where  more  than  one  operating  task  may  be  carried  on  at  the  same 
time. 


EXAMPLE:  On  an  intelligence  system,  a  user/operator  instructs  the 
system  to  generate  a  list  of  all  weapon  systems  by  type  located 
within  a  specified  geographical  area.  The  user/operator  knows 
from  experience  that  the  task  will  consume  appreciable  time.  The 
job  is,  therefore,  designated  as  a  background  task,  and  the  user/ 
operator  continues  processing  incoming  messages  in  the  foreground. 
When  the  machine  completes  the  background  task,  it  notifies  the 
user /operator  of  that  completion  by  appropriate  signals. 


3.3.3  BENEFITS  OF  PROVIDING  INTERRUPT  AND  WORK  RECOVERY  FEATURES 


Providing  system  design  features  to  permit  interrupts  and  facilitate 
work  recovery : 

a.  Reduces  error  rates,  by  minimizing: 

1.  Probability  of  error  due  to  requirement  for  entering 
redundant  information. 

2.  Increased  probability  of  error  associated  with  entry  of 
commands  and  data  which  are  only  rarely  used. 

3.  Attempts  to  complete  a  partially  finished  task  without 
provision  of  the  appropriate  task- contextual  cues. 

b.  Increases  system  throughput  rates,  by  minimizing: 

1.  Requirements  for  redoing  work  lost  during  system  failure. 

2.  Requirements  for  redoing  work  interrupted  by  higher- 
priority  tasks. 

3.  Requirements  for  the  system  to  reprocess  information  when 
an  active  task  was  interrupted  because  of  system  failure 
or  the  presence  of  higher-priority  tasks. 

4.  Necessity  for  reevaluating  the  context  in  which  an  inter¬ 
rupted  task  was  being  performed. 

5.  Lack  of  an  ability  to  perform  any  operations  during 
conditions  of  partial  system  failure. 

6.  Lack  of  available  reference  materials  to  reestablish 
full  operational  status  following  restart. 

7.  Excess  time  required  to  restart  system  after  relocating 
it  or  its  elements. 

8.  Time  required  to  specify  detailed  system  restart  instruc¬ 
tions. 

9.  Time  required  to  reenter  data  which  was  lost  due  to  inter¬ 
ruption  or  system  failure. 

c.  Reduces  user/operator  frustration  and  irritation,  by  minimizing: 


1.  Requirements  for  entry  of  redundant  information. 

2.  Destruction  of  partially  completed  tasks  on  receipt  of 
high-priority  information. 


3.3-4 


Reduces  data  base  integrity  compromises,  by  minimi  ■sing  the  loss 
Of  information  being  processed  or  entered  at  the  time  of  system 
failure  or  interruption  of  user/operator  activities  by  higher 
priority  tasks. 

Reduces  compromise  of  system  or  network  configuration  integrity 
by  minimizing  the  requirement  to  perform  detailed  system-  and/or 
network-configurational  command  entry  at  each  system  restart. 


3.3.4  METHODS  FOR  DEALING  WITH  INTERRUPTS  AND  WORK  RECOVERY 

a.  Alternative  sensory  channels.  If  a  system  incorporates  alterna¬ 
tive  sensory  channels  (e.g.,  CRT,  hardcopy,  and/or  computer¬ 
generated  speech  output;  keyboard,  light  pen-menu,  and/or  voice 
input)  then  the  channel  used  for  secondary  purpose  can  be  used 
for  interrupt  situation. 

EXAMPLE:  In  a  tactical  command  and  control  system,  the  normal 
display  is  a  CRT  screen.  If  the  CRT  fails,  operations  can  con¬ 
tinue  (in  a  degraded  mode)  if  normal  CRT  outputs  can  be  presented 
on  a  nearby  printer  or  via  computer-generated  speech. 

EXAMPLE:  In  an  intelligence  processing  system,  the  user/operator 
is  performing  a  routine  transaction  when  a  priority  message 
arrives.  A  bell  sounds  on  the  console  and  a  computer-generated 
voice  announces  the  presence  of  the  priority  message  in  the 
queue. 

b.  Multiple  displays.  When  a  system  incorporates  multiple  displays 
at  a  single  workstation,  the  display  not  currently  in  use  can 
provide  backup  for  interrupts  and  work  recovery. 

EXAMPLE:  A  logistics  system  employs  two  alphanumeric  displays 
to  provide  simultaneous  presentation  of  extensive  data  required 
for  complex  transactions.  If  one  CRT  fails,  system  software  can 
enable  continued  operations  by  using  the  remaining  display  and 
scrolling  techniques,  coupled  with  special  "format  scrambling" 
procedures  to  present  associated  data  items  on  the  same  display 
frame. 


EXAMPLE:  An  intelligence  system  uses  a  terminal  incorporating 
two  alphanumeric  displays.  If  a  high  priority  message  arrives, 
the  system  displays  a  warning  message  in  reserved  areas  of  both 
displays.  The  screen  not  presently  receiving  data  then  is  used 
to  deal  with  the  priority  message.  Upon  completion  of  the  priority 
transaction,  this  screen  is  restored,  and  t)ia  routine  transaction 
is  resumed  on  the  original  screen. 

c.  Retention  of  interrupt  state.  Whan  an  interruption  occurs  in 
normal  operations,  the  system  automatically  stores  data  and 
commands  related  to  tiuj  current  transaction. 

EXAMPLE:  A  user /osier a tor  is  working  on  a  routine  message  in 
an  artillery  command  and  control  system  when  a  priority  message 
arrives.  The  system  automatically  halts  the  current  transaction, 
immediately  places  an  alerting  message  in  the  warning  or  error 
message  area  on  the  display  screen,  saves  all  data  and  commands 
from  the  in-progress  transaction,  clears  the  screen,  and  then 
displays  the  priority  message. 


EXAMPLE:  A  usor/operator  is  performing  routine  transactions  in 
a  personnel  accounting  system  when  external  power  suddenly  fails 


An  on-board  emergency  power  source  cuts  in  automatically, 
providing  power  enough  for  emergency  software  routines  to  save 
the  entire  contents  of  volatile  storage  and  displays  on  a  disk 
pack. 

Automatic  file  naming  and  storage.  Throughout  routine  operating 
sessions,  the  system  periodically  performs  an  automatic  "save"  of 
all  data  and  commands  generated  since  the  last  such  save.  It 
automatically  generates  a  file  name  linked  to  the  user's/oper¬ 
ator's  ID,  then  saves  all  data,  results,  and  commands  active 
at  the  time  of  the  save.  Each  new  periodic  save  purges  the  pre¬ 
ceding  file. 

EXAMPLE:  A  user/operator  is  working  with  the  Ground  Order-of- 
Battle  (GOB)  File  in  an  intelligence  system.  Once  an  hour,  the 
system  generates  a  file  name  linked  to  this  individual  (e.g., 
"GOB. SMITH. 9267)  and  saves  the  current  GOB  in  a  file  with  that 
name,  along  with  the  current  contents  of  the  display  screen  and 
any  commands  presently  active.  It  does  this  without  Smith's 
participation  or  even  knowledge. 

Standard,  editable  start-up  configurations.  When  normal  opera¬ 
tions  are  interrupted  for  any  reason,  software  routines  are  used 
to  guide  resumption  of  operations.  Such  routines  are  provided 
for  each  workstation  as  needed,  and  for  the  system  as  a  whole. 

EXAMPLE:  A  tactical  command  and  control  system  has  just  com¬ 
pleted  a  routine  move.  The  system  has  been  powered  up  and 
diagnostic  routines  have  run  successfully.  The  last  step  in  the 
diagnostic  routine  is  to  invoke  startup  software.  This  software 
guides  the  user/oporator  through  the  steps  required  to  establish 
the  communication  network:  identify  each  terminal  by  type, 
function,  and  security  status:  identify  user  groups?  and  perform 
any  other  procedures  necessary  to  prepare  for  normal  operations. 
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3.3.5  RECOMMENDATIONS  FOR  INTERRUPTS  AND  WORK  RECOVERY 

a.  Table  3.3-1  presents  general  recommendations  for  using  particular 
methods  for  interrupts  and  work  recovery.  Before  deciding  on 
specific  methods,  the  reader  should  review  the  recommendations 
presented  in  this  section  and  the  advisory  comments  on  interrupts 
and  work  recovery  in  Section  3.3.6. 


Table  3.3-1.  Method  for  Dealing  with  Interrupts  and  Work 
Recovery  by  Application 
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b.  Provide  automatic  safeguards  to  prevent  errors  from  entering 
system  data  bases  during  system  failures. 

c.  If  entries  made  during  one  transaction  will  be  relevant  to  a 
subsequent  transaction,  require  the  system  to  "remember"  these 
entries  if  failure  occurs  during  the  subsequent  transaction. 

d.  If  work  is  halted  by  a  higher -priority  message  or  task,  provide 
the  capability  to  restore  the  system  precisely  to  the  point  at 
which  the  original  work  was  interrupted. 

e.  During  entry  of  multiple  data  items,  allow  the  user/operator 
to  interrupt  his/her  own  work  and  recover  by  restarting, 
canceling,  or  changing  any  item  before  taking  a  final  enter 
action. 

f.  If  data  entries  or  changes  wili  be  nullified  by  an  abort  action, 
present  the  potentially  nullified  entries  on  the  display  and 
require  the  user /operator  to  confirm  the  abort. 

g.  Provide  the  capability  to  allow  the  user/operator  to  "take  back" 

or  undo  the  effects  of  at  least  the  immediately  preceding  action. 

h.  Even  if  errors  have  been  committed,  do  not  permit  escape  from  a 

partially  completed  transaction  to  result  in  incorrect  or  accidental 
modification  of  stored  data  or  in  initiation  or  modification 

of  other  system  functions. 

i.  When  the  user/operator  signals  the  end  of  a  transactional  session, 
check  all  pending  transactions  to  determine  whether  the  danger 
exists  that  data  will  be  lost.  Tf  so,  advise  the  user/ojxjrator 

of  this  likelihood  before  completing  the  logoff  procedure. 

j.  Do  not  allow  any  error  by  the  user /operator  to  terminate  or  abort 
the  transactional  session. 

k.  If  the  user/operator  eamiot  meet  the  security  requirements  for 
part  of  the  data,  do  not  terminate  or  abort  the  transactional 
session. 

l.  If  the  user/operator  cannot  meet  the  security  requirements  for 
part  of  the  data,  do  not  impede  access  to  that  portion  of  the 
data  for  which  the  user/operator  is  cleared. 
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3.3.6  ADVISORY  COMMENTS  ON  INTERRUPTS  AND  WORK  RECOVERY 


Alternative  sensory  channels 


1.  Use  alternative  sensory  channels  to  warn  the  user/operator 
of  incoming  priority  messages  or  tasks. 

2.  Use  alternative  sensory  channels  to  warn  the  usar/operator 
of  partial  equipment  failures. 

3.  Use  alternative  sensory  channels  to  maintain  continuity 
of  operations,  even  if  in  a  degraded  mode. 

b.  Multiple  display  devices 

1.  Display  warning  messages  concerning  imj  ending  intenupts 
in  reserved  areas  on  both  displays. 

2.  Whenever  possible,  use  the  alternative  display  to  deal  with 
interrupt  conditions.  For  exanple,  if  the  user/opera cor 

is  entering  data  on  the  alphanumeric  screen  v.’hen  a  high- 
priority  message  arrives,  use  the  graphics  screen  to  proc¬ 
ess  the  message,  leaving  the  alphanumeric  screen  contents 
intact  to  facilitate  resumption  of  the  routine  transaction. 

c.  Retain  interrupt  state 

1.  When  routine  operations  must  be  interrupted  because  of 
higher  priority  work  or  partial  functions,  always  save 
all  data  and  commands  related  to  current  transactions. 

2.  After  the  cause  of  an  interruption  has  been  removed  through 
processing  or  repair,  advise  the  user/operator  that  normal 
operations  can  be  resumed.  Provide  a  single  action  (e.g., 
menu  option,  yes/no  question,  function  key)  to  reload  data 
and  commands,  restore  displays,  and  continue  routine  opera¬ 
tions  from  the  point  at  which  interrupted. 

•1.  Automated  file  naming  and  storage 

1.  When  periodic  "saves"  are  made  of  data,  active  commands,  and 
screen  contents,  also  save  the  date  and  time,  the  user's/ 
operator's  logon  information,  the  transaction  type  (e.g., 
data  base  update) ,  and  any  other  information  that  will  help 
to  identify  the  file. 

2.  Maintain  a  list  of  periodically-saved  files  currently  avail¬ 
able  for  user/operator  review. 

3.  After  the  cause  of  an  interruption  has  been  removed,  provide 
the  user/operatoi  with  the  option  to  resurms  the  interrupted 
operation,  or  to  defer  that  operation  while  doing  something 
else.  If  the  user/operator  elects  to  defer  the  interrupted 
operation,  hold  the  "interrupt  file"  until  needed. 
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4.  Provide  a  capability  for  a  user/operator  to  review  files  on 
interrupted  operations  that  are  keyed  to  his/her  logon  ID. 

5.  Do  not  permit  users/operators  to  review  files  on  interrupted 
operations  not  keyed  to  their  logon  IDs  unless  they  have 
specific  authority  to  do  so. 

e.  Standard,  editable  startup  configurations 

1.  Provide  software  to  save  a  table  containing  the  current 
system  configuration  on  peripheral  storage  as  part  of  the 
shutdown  procedure. 

2.  After  power-up  and  automatic  diagnostics,  automatically 
load  the  system  configuration  that  existed  prior  to  the 
interruption  of  service.  Display  this  configuration  to 
the.  user/operator  and  pro*1 -i.de  the  following  options: 

{a)  Accept  the  configuration  as  is. 

(b)  Edit  the  displayed  configuration. 

(c)  Cancel  the  displayed  configuration  and  construct  an 
entirely  new  configuration. 
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SECTION  4.  MESSAGE  COMPOSITION  AIDS 


Information  in  this  category  bears  on  methods  for  enhancing  user/operator 
capabilities  for  generating  messages  and  message  elements.  Two  categories  of 
messages  are  considered: 

1.  Alphanumeric  messages,  where  information  is  of  a  textual  or 
tabular  nature. 

2.  Graphic  displays,  where  information  is  of.  a  pictorial,  dia¬ 
grammatic,  or  representational  nature. 
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4.1.1  DEFINITION 

Alphanumeric  messages  are  created  out  of  standard  alphabetic  and  numeric 
symbols.  To  the  extent  that  standard  grammatical  symbols  are  required  for 
textual  presentation  or  for  other  types  of  separations,  or  that  special  sym¬ 
bols  associated  with  a  specific  area  of  science  or  technology  are  required, 
alphanumeric  messages  also  contain  these  additional  symbols  and  symbol  sets. 
Alphanumeric  messages  consist  of:  free  text  messages  and  reports;  tabular 
presentation  of  data;  and  system  HELP  files  and  other  types  of  system  support 
aids.  In  addition,  alphanumeric  messages  are  almost  always  associated  with 
graphic  presentations.  In  this  context,  they  are  labels,  other  identifiers, 
and  explanatory  notations. 

Alphanumeric  message  composition  aids  guide  the  user/operator  to  efficient 
construction  of  correct  and  complete  alphanumeric  messages  and  reports. 


[#j  r 


C  MES: 


e  appropna 


e  a  fixed  f 


NOTE:  Full  fixed  alphanumeric  message  formats  are  system- 
provided  and  cannot  be  altered  by  the  user/operator. 

EXAMPLE:  In  a  field  medical  unit,  a  weekly  medical  supplies 
requisition  is  required.  The  list  requires  the  following 
information:  item  name,  item  code,  size,  quantity,  perisha¬ 
bility  status,  date  needed,  substitution  acceptable  or  not. 
The  system  provides  no  report  format  for  the  requisition. 

The  user/operator  generates  a  tabular  "shell"  with  the 
appropriate  column  headings  and  stores  it  in  the  machine. 
Each  week,  now,  the  user/operator  calls  up  the  "shell"  and 
completes  the  requisition. 


Generation  of  variable  format  messages,  or  message  elements 


which  have  a  variable  format. 


EXAMPLE:  In  a  personnel  system,  data  is  usually  received  in 
a  standard  format  on  printed  forms.  However,  several  different 
forms  are  used  and  occasionally  data  are  received  in  unstruc¬ 
tured  verbal  reports.  Forcing  the  user/operator  to  enter  such 
data  in  a  standard  fixed  sequence  is  an  unnecessary  burden 
since  the  system  has  the  capacity  to  sort  it  out  correctly 
once  it  is  entered. 

Generation  of  free  text  messages.  NOTE:  strictly  speaking, 
the  very  act  of  creating  a  free  text  message  makes  it  a  vari¬ 
able  format  message  or  even  a  one-of-a-kind  fixed  format  mes¬ 
sage.  However,  there  are  some  aspects  of  generation  of  free 
text  messages  for  which  guidance  is  appropriate  and  is  differ¬ 
ent  from  guidance  provided  for  either  fixed  or  variable  type 
message  construction. 

EXAMPLE:  In  a  field  artillery  system,  the  tank  commander 
files  a  situation  report  at  the  end  of  each  training  maneuver. 
Instructions  for  construction  of  this  free  text  report  advise 
that  the  order  of  importance  in  reporting  is:  successful 
aspects  of  the  mission;  unsuccessful  asp-cts;  identification 
of  problems  and  deficiencies,  especially  as  these  relate  to 
unsuccessful  aspects;  strategies  for  correction  of  problems 
and  deficiencies;  training  implications;  and  methods  for 
reinforcing  successful  training  apsects.  The  commander 
creates  a  unique  report  based  on  actual  conditions  expe¬ 
rienced. 
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4.1.3  BENEFITS  OF  COMPOSITION  AIDS  FOR  ALPHANUMERIC  MESSAGES 

Use  of  composition  aids  in  the  construction  of  alphanumeric  messages 
will  enhance  overall  system  performance  through  improved  user/operator 
performance  by: 

a.  Reducing  error  rates,  by  minimizing: 

1.  The  need  to  reformat  standard  messages  or  system  inputs 
each  time  data  are  entered,  thereby  increasing  the  oppor¬ 
tunity  for  typographical  error. 

2.  Imperfect  recall  of  message  or  report  requirements. 

b.  Increasing  system  throughput  rates,  by  minimizing: 

1.  Time  to  generate  lengthy  message  formats  for  data  entry. 

2.  Time  to  correct  errors  in  message  format. 

c.  Reducing  user/operator  frustration: 

a.  By  minimizing  the  requirement  to  conform  to  message 
format  and/or  content  requirements. 

b.  By  minimizing  the  need  to  refer  to  system  documentation 
for  determination  of  message  format  and/or  content 
requirements. 


I 
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4.1.4  METHODS  FOR  AIDING  ALPHANUMERIC  MESSAGE  COMPOSITION 


a.  Form  filling  from  legal  entries.  Construction  of  fixed  message 
segment  formats  for  use  of  legal  entries  is  appropriate  for 
situations  where  data  entry  requirements  are  rigid,  i.e.,  where 
a  list  of  legal  entries  is  available  either  on-line  or  in  a  legal 
data  entry  code  book  or  manual. 

Data  entry  format:  AMMO  TYPE:  ; 


Form  filling  from  linked  HELP  files.  Construction  which  makes 
use  of  linked  HELP  files  to  structure  fixed  message  segment 
formats  is  highly  appropriate. 


Data  entry  format:  EQUIP: 


First  HELP  file: 


Data  entry  format: 


Second  HELP  file: 


r - 

EOUIPfCNT  TYPE 

LETTER  CODE 

COMBAT  EQUIPtfNT 

CC 

AIR  EQUIPMENT 

AI 

TRANSPORTATION  EQUIPMENT 

TR 

ENGINEERING  EQUIPMENT 

EN 

etc. 

1 _ 

_ a 

ESQUIP:  if  J _ i 

f - 

COMBAT  EQUIPHENT  TYPE 

LETTER  CODE 

ARMORED  EQUIPMENT 

ARM 

COHUNO  CONTROL  EQUIPMENT 

CHO 

INFANTRY  EQUIPMENT 

INF 

etc. 

; 

Data  entry  format: 


EQUIP: 
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c.  Direct  entry  from  system  data.  Construction  of  fixed  message 
segment  formats  for  direct  entry  from  stored  data  is  a  viable 
method,  but  one  for  which  there  may  be  only  limited  opportu¬ 
nity  available  to  the  user/operator.  One  specific  application 
of  such  a  measure  is  the  current  time  entry  in  a  system  with 
such  a  capability.  Since  the  computer  already  "knows"  to  read 
current  time  from  the  system  clock,  the  user/operator  can 
designate  a  current  time  data  entry  field  and  the  system  will 
make  a  correct  entry  into  this  segment  of  the  fixed  format 
message. 


d.  Direct  entry  from  user/operator-entered  data.  As  with  data 
entry  from  system  data,  limited  application  may  also  be  found 
for  direct  entry  of  data  from  data  previously  entered  by  the 
user/operator.  Computer-propagated  data,  i.e..  replication 
of  previously  entered  data,  and  computer-generated  data,  i.e., 
data  calculated  on  the  basis  of  previously  entered  data,  can 
be  automatically  accessed  and  displayed. 


e. 


Linked  menus.  Linked  menus  can  be  used  to  structure  fixed 
format  message  segments  in  a  fashion  similar  to  that  discussed 
for  linked  HELP  files.  The  primary  difference  is  that  the 
menus  are  formatted  in  the  form  of  questions. 


IH  VXAT  T¥P€  Of  EQUIPMENT  ME  TOO  INTERESTED? 

T.  CO  —  COMBAT  EQUIPMENT 

2.  At  —  AIR  EOtMPHENT 

3.  Tfl  —  TRANSPORTATION  EQUIPMENT 

4.  EN  —  ENGINEERING  EQUIPMENT 

5.  tic. 


CO 


IN  WAT  TYPE  Of  COMBAT  EQOlPtCNT  ME  YOU  INTERESTED? 

1 .  AW  —  ARMORED  EQUIPMENT 

2.  CIC  —  COMWO  NO  CONTROL  EQOIPKKT 

3.  IN?  —  INFANTRY  EQUIPtCVT 

4.  etc. 


-•»  AW 


V 
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Cursor  control  dialog.  Cursor  control  dialog  is  usually  a 
special  form  of  menu  dialog  in  which  the  cursor,  which  may 
be  moved  with  a  variety  of  positioning  devices,  is  placed 
next  to  or  over  the  desired  entry.  Con;truction  of  fixed 
message  segment  formats  is  suitable  for  situations  amenable 
to  menu  presentation  and  direct  entry  through,  for  example, 
a  light  gun,  a  joystick,  a  touch  sensitive  pad. 
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RECOMMENDATIONS  FOR  COMPOSITION  AIDS  FOR  ALPHANUMERIC  FORMATS 


a.  Table  4.1-1  presents  recommendations  for  using  particular  methods 
for  aiding  the  user/operator  in  composition  of  alphanumeric  mes¬ 
sages.  Before  deciding  to  use  one  or  more  of  these  methods, 
review  the  general  recommendations  that  follow  and  consult  the 
advisory  comments  on  specific  methods  contained  in  Section  4.1.6. 

Table  4.1-1.  Methods  for  Aiding  Alphanumeric  Message  Composi¬ 
tion  by  Type  of  Format  Application 


KEY 

APPLICATION  1 

1  - 

2  - 

3  - 

4  - 

RECOWENDED 

ACCEPTABLE 

WORKABLE  BUT  SUB0PT2MAL 

NOT  RECOMMENDED  OR  NOT  APPLICABLE 

FIXED 

ALPHANUMERIC 

FORMAT 

VARiALBE 

ALPHANUMERIC 

FORMAT 

FREE 

TEXT 

FORMAT 

FORM  FILLING  FROM  LEGAL  ENTRIES  LIST 

i 

i 

4 

FORM  FILLING  FROM  LINKED  HELP  FILES 

i* 

i 

4 

Q 

S 

DIRECT  ENTRY  FROM  SYSTEH  DATA 

i 

2 

3 

UJ 

£ 

DIRECT  ENTRY  FROM  USER/OPERATOR  ENTERED  DATA 

2 

2 

1* 

LINKED  MENUS 

2 

1* 

1 

CURSOR  CONTROL  DIALOG 

2 

2 

2 

‘Recommended  as  1st  choice  for  standardization  purposes. 
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4.1.6  ADVISORY  COMMENTS  FOR  AIDS  FOR  ALPHANUMERIC  MESSAGE  COMPOSITION 


Form  filling  from  legal  entries 


1.  Form  filling  from  legal  entries  is  appropriate  when  the 
user/operator  can  transfer  information  (commands  or  data) 
to  the  screen  from  a  hard-copy  source.  Make  the  sequence 
of  entries  consistent  from  hard  copy  to  screen  to  reduce 
the  requirement  for  cursor  movement.  It  is  also  helpful 
if  the  screen  display  resembles  the  hard-copy  format. 

2.  Avoid  form  filling  from  legal  entries  when  requirements 
for  completion  of  segments  of  the  form  are  variable,  i.e., 
conditional,  optional,  single  and/or  multiple  entry’  allowed. 

3.  Avoid  form  filling  from  legal  entries  when  the  system  would 
be  required  to  shift  from  form  to  form.  This  slow  type  of 
data  entry  is  particularly  inappropriate  when  the  system's 
data  transmission  rate  is  low. 

4.  ’""bedded  menus  are  simplified  and  relatively  error-free 
...H'l'ds  for  provision  of  form  filling  from  legal  entries. 
..owever,  such  formats  use  excessive  storage  space  and  may 
not  be  feasible  under  given  system  limitations. 

Form  filling  from  linked  HELP  files 

1.  Form  filling  from  linked  HELP  files  is  particularly  use¬ 
ful  where  low  system  storage  capacity  limits  the  amount 
of  information  which  can  be  placed  on  data  entry  display 
menus — either  straight  menu  presentation  or  format- 
imbedded  menus — or  in  a  series  of  HELP  files. 

2.  Form  filling  from  linked  HELP  files  is  especially  appropri¬ 
ate  when  the  information  being  handled  is  of  a  hierarchical 
nature . 

3.  Where  the  sophistication  of  users/operators  is  uneven  and/ 
or  likely  to  improve  over  time,  the  availability  of  dif¬ 
ferent  levels  of  linked  HELP  files  is  important  and  can 
contribute  to  a  significant  savings  of  system  time. 

Direct  entry  from  system  data 

1.  Allow  the  user/operator  control  over  the  amount  of  informa¬ 
tion  directly  entered  from  system  data.  For  example,  the 
user/operator  may  wish  to  truncate  a  long  listing  of  infor¬ 
mation  or  to  delay  its  output  until  a  later  time. 

2.  Allow  the  user/operator  to  establish  the  presentation  for¬ 
mat  for  system-entered  data.  Under  these  circumstancos, 
the  user/operator  could  call  out  the  format  specifications 
and  the  system  could  automatically  provide  the  correct  data 
in  the  correct  portion  of  the  format. 
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3.  Allow  the  user/operator  to  change  a  computer-generated 
value  by  providing  a  TAB  BACK  function  key  which  moves 

the  cursor  back  to  the  initial  character  of  the  data  field. 

4.  When  the  computer  automatically  fills  a  data  field,  allow 
the  cursor  to  automatically  skip  across  the  field  to  the 
next  field  in  which  the  user/operator  is  to  make  an  entry. 

5.  When  the  computer  inserts  data  from  a  previous  entry  or 
calculates  an  entry  from  previously-entered  data,  display 
the  data  as  a  default  value. 

d.  Direct  entry  from  user/operator-entered  data 

1.  Provide  some  simple  construction/language  usage  HELPS  to 
the  user/operator. 

(a)  in  report  preparation,  use  active  rather  than  passive 
construction . 

EXAMPLE:  _ USE _  DO  NOT  USE 

The  Commander  It  was  stated  by 

stated  that  .  .  .  the  Commander 
that  „  .  . 

(b)  Use  short,  simple,  declarative  statements,  thereby 
clearly  identifying  the  main  topic. 

(c)  Use  affirmative  statements  in  reports;  use  negative 
statements  to  provide  cautions  against  actions  to  be 
specifically  avoided.  When  presenting  cautions, 
maintain  a  consistent  format  and  introduce  the  caution 
by  a  standard  symbol. 

(d)  Use  simple  terms  and  use  them  consistently. 

2.  Use  standard  terms,  codes,  abbreviations  that  appear  in 
doctrinal  literature  or  that  are  familiar  to  the  intended 
user/operator  population  in  labeling  data  entry  fields. 

3.  Use  standard  field  delimiters  for  constructing  alphanumeric 
messages  and  formats  for  alphanumeric  messages. 

4.  When  the  computer  inserts  data  £_om  a  previous  entry  or 
calculates  an  entry  from  previously  entered  data,  display 
the  data  as  a  default  value. 

e.  Linked  menus 


1.  Use  linked  menus  when  a  hierarchical  menu  structure  is 

appropriate,  i.e.,  when  sequentially  more  and  more  refined 
selection  is  to  be  made. 
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4.2.1  DEFINITION 


Graphics  displays  are  screen  and  hardcopy  diagrammatic  and  pictorial  pre¬ 
sentations.  To  a  greater  extent  than  for  alphanumeric  message?  and  message 
segments/  the  content  and  structure  of  graphics  displays  are  at  the  discretion 
of  the  user/operator.  Thus,  advising  the  user/operator  on  graphics  display 
construction  has  great  importance. 

Construction  of  graphics  displays  can  become  very  complicated;  a  system 
with  graphics  capability  can  add  a  great  number  of  dimensions  and  a  great 
amount  of  versatilitv  to  system  output.  Without  proper  utilization  of  this 
graphics  capability,  however,  inferior  output  will  occur.  Yet,  it  is  not  the 
function  of  this  information  to  provide  a  course  of  instruction  or  even  a 
"tutorial"  to  the  user /operator  in  composition  of  graphics  displays.  Thus, 
there  must  be  transparent  features  of  the  system  which  lead  the  user/operator 
to  construction  of  "good"  rather  than  "bad"  graphics  displays. 


4.2.2  APPLICATIONS  FOR  COMPOSITION  AIDS  FOR  GRAPHICS  DISPLAYS 


Composition  aids  for  graphics  displays  are  appropriate  for  user/operator 


use  in: 


a.  Creation  of  maps  and  charts. 


EXAMPLE:  The  tank  battalion  commander  requests  that  one  of  the 
forward  tanks  provide  a  description  of  the  terrain  immediately 
ahead.  The  user/operator  in  the  lead  tank  creates  a  rough  map 
of  the  area  by  sketching  with  a  light  pen  and  calling  up 
standard  mapping  symbols  already  stored  in  the  machine  and 
placing  them  at  appropriate  locations  on  the  map .  Alphanumeric 
identifiers  are  also  added  to  call  out  important  terrain  fea¬ 
tures.  The  display  is  then  transmitted  to  the  tank  battalion 
commander. 
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b.  Creation  of  overlays  for  maps,  charts,  and  other  pictorials. 

EXAMPLE:  Through  the  combination  of  a  map  display  and  map 
overlay  capability,  an  artillery  unit  has  the  capacity  to 
graphically  portray  not  just  unit  loc*i‘ 'on  but  firing  orien¬ 
tation  as  well.  The  user/ operator  enteri  the  map  grid  in 
the  map  display.  By  calling  up  the  unit  and  equipment  symbols, 
entering  the  alphanumeric  coordinates  information  for  posi¬ 
tioning  the  symbol (s),  and  the  numeric  orientation  value  for 
the  desired  firing  direction,  the  unit's  location  and  firing 
orientation  are  stored  in  the  machine  and  displayed  on  the 
map  via  the  map  overlay. 


Creation  of  bar  charts,  histograms/  etc. 
quantitative  information. 


for  representation  of 


EXAMPLE:  For  a  logistics  function,  the  user/operator  wants  to 
make  a  graphics  display  of  comparision  of  available  and  author¬ 
ized  stock  levels  of  a  particular  piece  of  equipment  over  a 
twelve  month  period.  The  data  are  stored  in  the  computer  by 
equipment  type  and  retained  online  for  a  three  year  period. 

The  user/operator  specifies  the  following  to  the  computer  as 
data  to  be  dealt  with:  equipment  code;  time  frame;  authorized 
level,  to  be  displayed  as  100  percent  on  a  month  by  month 
basis;  and  peak  availability  during  the  month,  to  be  displayed 
as  a  percentage  of  the  authorized  level  on  a  month  by  month 
basis.  The  instruction  to  the  computer  includes  construction 
of  a  line  chart  for  authorized  level  (a  straight  line  at  the 
100  percent  level)  and  a  vertical  bar  chart  to  show  "peak 
monthly  availability." 
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Creation  of  free  form  drawings. 


EXAMPLE:  An  artillery  unit  wants  to  move  its  fire  units  to 
the  other  side  of  a  stream  which  is  too  deep  to  ford.  The 
Corps  of  Engineers  is  designated  to  build  a  pontoon  bridge 
to  facilitate  the  crossing.  As  part  of  the  request  and 
specifications  for  the  bridge,  the  artillery  commander  draws 
a  rough  map  and  transmits  it  to  the  engineering  unit. 
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4.2.3  8ENEFITS  OF  COMPOSITION  AIDS  FOR  GRAPHICS  DISPLAYS 


Use  of  composition  aids  in  the  construction  of  graphics  displays  will 
enhance  overall  system  performance  through  improved  user/operator  performance 
by: 

a.  Reducing  error  rates,  by  minimizing: 

1.  Inaccuracy  or  poor  judgment  in  placing  symbols  and  lines 
within  the  display. 

2.  Errors  in  specification  of  correct,  standard,  and/or 
doctrinal  symbology. 

3.  Imprecise  retrieval  of  data  to  be  displayed  through 
incomplete  or  inaccurate  specification. 

b.  Increasing  system  throughput  rates,  by  minimizing: 

1.  Time  required  to  position  desired  symbols  within  the 
graphics  display. 

2.  Time  required  for  direct  keyboard  entry  of  position  and 
symbols  identification  information. 

3.  Time  required  to  correct  errors  in  graphics  data  speci¬ 
fication  and  positioning. 

"jag'j  integrity,  .33  enhanced  by: 

a.  Reduced  misestimation  of  positioning  of  symbol,  or  points 
on  graphics  displays. 

b.  Conformity  to  standards  thereby  reducing  potential  for 
misinterpretation  of  the  graphics  display. 


4.2.4  METHODS  FOR  AIDING  GRAFHICS  DISPLAYS  COMPOSITION 


a.  Direct  entry  from  system  data.  Construction  of  graphics 

displays  from  system-stored  data  is  particularly  appropriate 
for  presentation  of  quantitative  data.  Data  retrieval  and 
layout  specifications  are  necessary.  The  availability  of 
stored  graphics  elements,  e.g.,  pictorial  symbols,  color 
associations,  which  are  in  conformance  to  standards,  enhances 
the  production,  authenticity,  and  accuracy  of  graphics  dis¬ 
plays  . 


b,  User/operator-entered  data.  Construction  of  graphics  dis¬ 
plays  from  usor/oporator-entercd  data  lias  the  greatest 
potential  for  versatility  of  graphics  displays.  Unless 
the  system  restrains  the  user/operator  from  generation  of 
inappropriate  graphics  displays,  however,  hard-to-inter- 
pret  "bad"  displays  may  result.  The  system  should  pro¬ 
tect  the  user/operator  from  generating  displays  which, 
for  example,  permit  inadvertent  destruction  of  display 
features  by  unintentional  ©verprnt,  bleeding  of  colors 
due  to  excessive  color  saturation,  or  masking  of  suc¬ 
cessive  lines  due  to  placement  of  lines  which  exceeds 
resolution  capability 
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c.  Linked  menus.  Linked  menus,  either  of  straight  alphanumeric 
construction,  or  preferably  of  a  combination  of  alphanumeric 
and  graphics  structure,  can  be  used  to  aid  in  the  composition 
of  graphics  displays. 
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THE  AVAILABLE  OPTIONS  AAt ; 

1.  (K  (THIEVE  DATA 

2.  S  HE  DATA 

T.  (ED  IT  DATA 

4.  (aO)O  A  FILE 

5.  OE  LETT  A  FILE 

6.  (01  (SPLAT  MT* 

ENTER  EESIRED  OPTION  . 
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THE  DEFAULT  STWOL  IS: 


iHAT  STWOL  00  TOO  UISH  TO  DISPLAY: 

1.  (CO)WAT  EQOIPWNT 

2.  (All*  EQUWNT 

].  (TXANSPORTATION  EOUIF'fNT 

4.  (EN)GtNEENlNG  EQUIPMENT 

5.  (HE)AVT  AA1IILE1T 

ENTER  DISHED  OPTION  -  ->  $ 


BUT  TYPE  OF  OATA  DO  TOO  WISH  TO  DISPLAY: 

1.  (AL)MANUWRIC 

2.  (NU)NERIC 

3.  (STjWOL 

ENTER  DESIRED  OPTION  ■  ■>  :> 
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d.  Digitization.  Digitisation  is  an  efficient  method  for  graph¬ 
ics  interaction  since  it  depends  to  a  large  extent  on  the 
features  and  capabilities  of  the  digitizing  device.  A  great 
variety  of  digitizing  devices  is  available,  as  discussed  in 
Section  1.2.4,  Methods  for  Graphics  Control.  Composition 
aids  for  digitization  are  linked  to  the  features  of  the 
device  and  to  the  specifications  for  data  output — usually 

a  form  of  imagery  or  map  displays. 

e.  Joystick,  light  pen,  trackball,  etc.  These  devices  are 
essentially  methods  for  placing  a  cursor  on  a  screen  for 
selection  or  entry  of  an  item  of  information.  Characteris¬ 
tics  of  a  variety  of  joystick  types,,  etc.,  are  discussed  in 
Section  1.2.4,  Methods  for  Graphics  Control.  Composition 
aids  for  these  interactions  are  linked  to  the  peculiar  fea¬ 
tures  of  the  equipment  and  to  the  specifications  for  the 
graphics  display  output. 

f.  Touch  sensitive  surface.  Creating  displays  through  use  of 
a  touch  sensitive  surface  is  essentially  a  cursor  applica¬ 
tion  which  makes  use  of  the  heat  registered  on  the  surface 
when  a  finger  is  pressed  against  it.  Graphics  display  com¬ 
position  by  this  method  is  subject  to  the  capabilities  and 
sensitivities  of  the  equipment  and  to  its  compatability  with 
the  requirements  imposed  on  the  graphics  display  output. 
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4.2.5  RECOMMENDATIONS  FOR  COMPOSITION  AIDS  FOR  GRAPHICS  DISPLAYS 

a.  Table  4.2-1  presents  recommendations  for  using  particular  methods 
for  aiding  the  user/operator  in  composition  of  graphics  displays. 
Before  deciding  to  use  one  or  more  of  these  methods,  review  the 
general  recommendations  that  follow  and  consult  the  advisory 
comments  on  specific  methods  contained  in  Section  4.2.6. 


Table  4.2-1.  Methods  for  Aiding  Graphics  Display  Composition 
by  Type  of  Format  Application 


4.2.6  ADVISORY  COMMENTS  FOR  METHODS  FOR  AIDING  GRAPHICS  DISPLAYS  COMPOSITION 


a.  Direct  entry  from  system  data 


1.  Allow  the  user/operator  control  over  the  amount  of  infor¬ 
mation  directly  entered  from  system  data.  For  example, 
the  user/operator  may  wish  to  restrict  presentation  of 
trend  data  by  time  interval,  or  curtail  the  number  of 
variables  presented  on  the  chart. 

2.  Allow  the  user/operator  to  establish  the  presentation 
format.  Under  these  circumstances  the  user/operator,  for 
example,  would  specify  the  length  of  the  "x"  and  "y"  axes 
of  a  chart,  as  well  as  the  intervals  along  each  dimension. 
These  features  could  be  established  most  easily  through 
menus  or  question  and  answer  dialog  techniques. 

3.  Allow  the  user/operator  to  change  a  computer-generated 
display.  For  example,  the  user/ opera tor  may  want  to 
extend  a  trend  analysis  on  the  basis  of  the  displayed 
parameters,  or  may  want  to  project  a  trend  on  the  basis 
of  modified  parameters. 

4.  Provide  a  standard  set  of  symbols  for  user/operator 
selection  appropriate  to  the  task.  Allow  the  user/ 
operator  placement  of  selected  symbols  and  alteration  of 
symbol  size  and  color,  if  a  color  capability  is  provided. 

b.  User/operator-entered  data 

1.  Allow  the  user/operator  direct  entry  of  data  for  incorpo¬ 
ration  into  graphics  displays  generated  as  direct  entry 
from  system  data. 

2 .  Give  the  user/ operator  access  to  standard  display  formats 
for  generation  of  graphics  such  as  bar  charts,  pie  charts, 
frequency  polygons.  Under  these  circumstances,  the  iden¬ 
tification  of  display  parameters,  e.g.,  intervals,  headings, 
colors,  is  at  the  discretion  of  the  user/operator. 

3.  Make  standard  graphics  symbology  available  to  the  user/ 
operator  for  incorporation  into  graphics  displays. 

Question  and  answer  and  menu  dialog  techniques  can  readily 
support  this  function.  If  color  graphics  are  possible, 
color  can  be  added  to  the  graphics  by  the  same  dialog 
technique (s) . 

4.  Allow  the  user/operator  to  employ  the  alphanumeric 
features  of  the  system  to  provide  headings  and  annota¬ 
tions  rather  than  providing  alphanumerics  as  a  product 

of  the  graphics  capabilities  (i.e. ,  by  "keying  in"  rather 
than  "sketching"  letters,  numbers,  and  standard  gram¬ 
matical  symbols) . 


Linked  menus 


1.  Provide  a  series  of  linked  menus  through  which  the  user/ 
operator  can  generate  standard  graphics  displays  such  as 
bar  charts,  frequency  polygons,  pie  charts.  The  linked 
menu  approach  allows  the  user/ operator  to  step  through, 
for  example,  selection  of  display  format?  identification 
of  data  categories;  dimensions  of  data  categories;  symbols 
and  their  placement. 

2.  Allow  the  user/operator  to  add  headings  and  annotations 
to  graphics  displays  through  the  use  of  linked  menus. 
According  to  what  capabilities  the  system  possesses,  such 
menus  step  the  user/operator  through,  for  example,  heading 
and  annotation  style  (upper/lower  case,  type  font,  type 
size);  location;  color;  and  color  intensity. 

Digitization 

1.  Make  the  user/operator  aware  of  the  accuracy  requirements 
of  the  particular  assignment  being  accomplished.  That  is, 
some  applications  may  require  very  precise  results  (maps 
drawn  for  targetting  purposes) ,  some  may  require  only 
minimal  precision  (rough  sketches  of  two  areas  under  pre¬ 
liminary  consideration  for  training  maneuvers) .  The 
user/operator  can  exercise  control  of  accuracy  through 
speed  with  which  digitization  is  performed. 

2.  Make  the  user/operator  aware  of  graphics  conventions 
required  for  correct  interpretation  of  products  of  digi¬ 
tization.  These  conventions  can  be  provided  through  a 
menu  or  question  and  answer  structure  for  each  relevant 
application  as,  for  example,  those  appropriate  to  showing 
topographic  versus  cultural  characteristics  of  a  given 
area  on  a  map. 

Joystick,  light  pen,  trackball 

1.  These  features  are  conducive  to  generation  of  simple 
graphics  such  as  line  drawings,  bar  charts,  frequency  poly 
gons  and,  in  fact,  provide  a  very  versatile  system.  The 
speed  at  which  the  joystick,  etc.,  moves  contributes  to 
the  accuracy  of  the  graphics  display  being  created. 

Allow  the  user/operator  to  adjust  or  control  cursor 
movement/speed  in  accordance  with  graphics  display 
accuracy  requirements. 

2.  Allow  the  user/operator  to  vary  the  width  of  the  line 
(image)  created  by  manipulation  of  the  joystick,  light 
pen,  trackball,  etc.  These  devices  do  not  independently 
have  the  capability  to  provide  line  width  variation. 
Variation  in  line  width  can  be  provided  by  "tieing  in"  a 
different  alphanumeric  key  to  the  joystick  capability. 

A  set  of  three  keys  would  permit  three  width  variations, 
four  keys  would  permit  four  variations. 


2.  Allow  the  user/operator  to  select  between  "dynamic"  and 

"static"  operation  of  the  touch  sensitive  surface.  In  the 
"dynamic"  mode,  the  cursor  continues  to  move  across  the 
surface  in  the  indicated  direction  at  some  set  pace  once 
the  user/operator  has  set  the  cursor  in  action.  In  the 
"static"  mode,  the  cursor  moves  only  at  the  command  of 
the  user/operator,  i.e.,  as  the  user/operator  touches  and 
retouches  the  touch  sensitive  surface. 
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SECTION  5.  DATA  RETRIEVAL  ASSISTANCE 


Guidelines  in  this  category  present  the  capabilities  required  to  sup¬ 
port  user/operator  interaction  with  system  data  bases.  Two  aspects  of  data 
retrieval  assistance,  user/operator  query  methods  and  query  structure, 
are  examined. 

1.  Query  Method.  Query  methods  are  the  ways  in  which  users/ 
operators  may  identify  the  characteristics  of  the  data  base 
contents  which  they  wish  to  review  or  alter. 

2.  Query  Structure.  Query  structure  relates  to  ways  in  which 
interaction  with  system  data  bases  may  be  organized,  structured, 
and  sequenced. 
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5.1  Query  Methods 


5.1.1.  DEFINITION 


Query  methods  are  techniques  by  which  the  user/operator  may  access  the 
data  base  and  identify  the  data  required  for  task  processing  by  the  system 
and/or  the  user/operator. 
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5.1.2.  APPLICATIONS  FOR  QUERY  METHODS 

Tasks  or  procedures  for  which  query  methods  are  applicable  include  those 
tasks  which  require  the  user/operator  to  interact  with  stored  data  or  data 
base  information. 


The  user/operator  will  have  occasion  to  check  portions  of  the 


data  base  to  verify  presence  and  accuracy  of  data 


EXAMPLE:  A  user/operator  may  be  required  to  confirm  a  last 
known  position  of  an  identifiable  troop  concentration.  If 
this  information  is  in  the  data  base,  entry  of  the  troop  ID 
code  should  display  troop  data  including  last  known  position 

the  user/operator  will  be  required  to  retrieve  information 


from  the  data  base  for  the  purpose  of  examination  and  evaluation. 


EXAMPLE:  The  user /operator  may  be  required  to  assign  50  rounds 
of  phosphorous  to  a  known  target  from  a  single  battery.  The 
data  base  should  confirm  ammunition  informatics  through  a 
query  with  the  battery's  ID. 

The  user/operator  will  frequently  retrieve  information  from  the 


data  base  for  deletion,  modification,  processing,  or  addition. 


EXAMPLE:  The  user/operator  may  be  required  to  update  certain 
perishable  data  in  the  data  base.  Update  will  likely  require 
all  of  the  following  steps:  identifying  the  data,  querying  the 
data  base,  retrieving  the  data,  examining  the  data,  entering 
the  proper  code(s)  to  gain  access  for  deletion  or  modification, 
and  deleting  or  modifying  the  data. 


5.1.3  BENEFITS  OF  QUERY  METHODS 


The  benefits  derived  from  the  use  of  user/operator  responsive  query 
methods  include: 

a.  Reduced  error  rates ,  by  minimizing: 

1.  Difficulty  in  manipulating  data  in  and  out  of  the  data  base. 

2.  ,  Skill  level  demands  on  user/operator  memory  or  concentration. 

b.  Increased  system  throughput  rates,  by  minimizing: 

1.  Time  for  access  to  information  required  for  and  vital  to 
mission  effectiveness. 

2.  Extended  time  for  use  by  the  user/operator  under  varied  or* 
undesirable  operating  conditions. 

c.  Increased  system  security,  by  including: 

1.  Methods  for  prevention  of  unauthorized  access  to  information 
resident  in  the  data  base. 

2.  Methods  for  prevention  of  unathorized  or  accidental  change/ 
deletion  of  data  base  information. 

d.  Decreased  training  time/complexity,  by  addressing: 

1.  Methods  adaptable  to  different  types  of  command  dialoqs. 
Retraining  may  not  be  required  on  new  command  languages, 
for  example. 

2.  Ease  in  manipulating  data  into  or  out  of  the  data  base. 
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5.1.4  METHODS  FOR  IMPLEMENTING  QUERIES 

a.  User-initiated  query  language  dialog,  in  which  the 
user/operator  enters  queries  in  response  to  a  prompt 
symbol  appearing  on  the  terminal.  The  prompt  is 
typically  brief,  so  the  user/operator  must  remember 
the  query  codes  and  options  and  accurately  type  them 
at  the  terminal. 

EXAMPLE:  The  user/operator  wants  to  retrieve  the  full 
file  content  of  today's  transactions  between  the  hours 
of  0945  and  1315.  The  user/operator  enters  "QUERY:" 
to  specify  dialog  type.  When  it  is  possible  for  the 
user/operator  to  obtain  the  file  content  by  entering 
the  code  for  file  type  "HI"  (for  historical  file)  and 
the  time  interva’  code  "0945-1315.” 


b.  Natural  language  dialog,  which  is  typically  user- 
initiated  query  language,  in  which  the  designer 
attempts  to  make  the  query  language  as  much  like 
standard  English  as  possible, 

EXAMPLE:  For  the  some  request  as  described  above 
for  user-initiated  dialog,  the  natural  language 
dialog  sequence  appears  on  the  screen  as  follows. 
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QUIT:  UTIICTt  THt  NIJIWIOU  HU  C9TO  <«.« 

Q*«SN  TO  Ills*. 


r 
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TH£  AVAILAALE  RETRIEVE  OPTIONS  ARE: 

I. 

(AC)TIVE  BATA  FILE 

2. 

(HI  ISTORICAL  BATA  FILE 

3. 

(FR)IEMH.Y  AJWOR  LOCATIONS 

4. 

(UN) FRIENDLY  ARMOR  LOCATIONS 

5. 

(ST)AAOAAD  REPORT  FORMAT 

ENTER  DESIRED  OPTION--* 

l 

i 

USt*  COOt  KMU1: _ •  _ 

activity  wrioeo:_m*t«t_totT 

UU 

ACTttt  EATA  Flu 
“historical  gata  nu 
“triiroly  utct  locations 

"1jNF*tl*0t.T  MKM  LOCATIONS 

3>«c«o  UK*r  format 


to  KNUI:, 


KUI  can  OESIMC?  tT/m 
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5.1.5  RECOMMENDATIONS  FOR  QUERY  METHODS 

Selection  of  the  query  method  depends  on  the  nature  of  the  system  being 
developed  and  the  characteristics  of  the  expected  users/operators  of  the  sys¬ 
tem.  Some  of  the  most  important  factors  in  making  this  decision  are: 

a.  Sophistication  of  the  users/operators: 

1.  HIGH  level  of  sophistication  means  that  users/operators 
are  very  familiar  with  the  system,  its  capabilities,  and 
the  sequences  of  operations  which  the  system  will  perform. 
Users/operators  with  a  HIGH  level  of  sophistication  will 
have  either  (a)  received  a  substantial  amount  of  train¬ 
ing  in  system  operation  or  (b)  had  considerable  experi¬ 
ence  in  operating  the  system  by  the  time  they  are  called 
on  to  use  it  in  operational  situations,  or  (c)  both  of 
the  above . 

2.  MEDJUM  level  of  sophistication  means  that  users/  opera¬ 
tors  are  quite  familiar  with  the  most  important  capa¬ 
bilities  and  commands  of  the  system,  but  are  not 

l  intimately  familiar  with  little-used  system  features. 
Users/operators  with  a  MEDIUM  level  of  sophistication 
may  have  received  considerable  training,  but  will  not 
use  the  system  enough  to  maintain  their  knowledge  about 
all  of  the  system's  capabilities. 

3.  LOW  level  of  sophistication  means  that  users/operators 
are  familiar  only  with  the  "big  picture"  of  system  opera¬ 
tion.  They  may  be  unfamiliar  with  the  range  of  capabili¬ 
ties  of  the  system. 

4.  VARIABLE  level  of  sophistication  means  that  different 
users/operators  have  different  levels  of  sophistication 
in  using  the  system.  Some  may  be  very  familiar  with 
its  features  and  capabilities,  while  others  will  be 
aware  of  only  the  most  elementary  and  important  features. 

b.  Requirements  of  data  retrieval  type: 

1-  ROUTINE — output  format  and  data  fields  are  substantially 
constant  either  between  reports  or  for  single  reports 
produced  frequently. 

2.  NONRQUTINE — output  format  and  data  fields  are  unpre¬ 
dictable  and  vary  over  a  wide  range  for  single  reports 
and  across  reports. 

3>  VARIABLE— output  format  and  data  fields  are  constant  for 
a  section  of  outputs,  but  not  predictable  for  individual 
reports  or  sections. 
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c.  Daily  usage — number  of  times  typical  query  will  be  used  by  a 
typical  user/operator  in  a  given  period  of  time. 

1.  HIGH — typical  query  used  5  times  per  day  or  more. 

2.  MEDIUM — typical  query  used  twice  per  week  or  more  but 
less  than  5  times  per  day. 

3.  LOW — typical  query  used  less  than  twice  per  week. 

d.  Computer-to-terminal  data  transmission  rate. 

1.  HIGH — 4800  baud  (480  characters  per  second)  or  greater. 

2.  MEDIUM — 1200  baud  (120  characters  per  second)  or 
greater,  but  less  than  4800  baud  (480  characters  per 
second) . 

3 .  LOW — less  than  1200  baud  (120  characters  per  second) . 

e.  Number  of  queries  in  usage. 

1.  HIGH — 46  or  more  queries  available  for  use  with 
the  system. 

2.  MEDIUM — 16  to  45  queries  available. 

3.  LOW— 15  or  less  queries  available. 

f.  Table  5.1-1,  Query  Method  by  System  and  System  User  Character¬ 
istics,  presents  a  general  list  of  recommendations  for 
selecting  query  types..  Before  making  a  final  decision, 
consult  the  specific  recommendations  for  individual  query 
types  in  Section  5.1.6, 

Tc  use  the  table,  first  decide  what  system  and  system  user  char¬ 
acteristics  apply  to  the  situation  you  are  considering.  Elimi¬ 
nate  any  query  types  where  a  "4"  appears  as  an  entry.  Select 
the  best  query  type  by  comparing  the  remaining  types  in  view 
of  the  characteristics  of  the  system  you  are  conceptualizing 
of  designing. 
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Table  5.1-1. 


Query  'Method  by  System  and  System  User 
Characteristics. 


RECOWENOEO 

CHARACTERISTICS  OF  SYSTEM  OR  SYSTEM  USER  j 

ACCEPTABLE 

SOPHISTICATION 
or  USERS 

REQUIREMENTS  OF 

OATA  RETRIEVAL  TYPE 

OAILY  USAGE  Of 
TYPICAL  QUERY 

COMPUTER  TO  TERMINAL 
TRANSMISSION  RATE 

NUMBER  OF  | 

QUERIES  IN  USAGE  | 

NOT  RECOW1ENOED  OR  NOT  APPLICABLE 

HIGH 

MED 

LOW 

VAR 

ROUTINE 

non¬ 

routine 

VAR 

NIGH 

NED 

LOW 

HIGH 

MEDIUM 

LOW 

HIGH 

MED 

LOW 

QUERY  LANGUAGE 

1* 

t 

3 

3 

t* 

!• 

1* 

1* 

2 

3 

\* 

2 

3 

1* 

71 

1 

NATURAL  LANGUAGE 

3 

3 

3 

3 

I 

2 

2 

3 

3 

2 

2 

2 

2 

* 

2 

3 

MENUS 

3 

1* 

1* 

1* 

. 

T 

1 

1 

2 

2 

I 

2 

4 

2 

2 

1 

FILL—  IN— THE— BLANKS 

2 

2 

3 

3 

2 

1 

3 

4 

3 

3 

2 

2 

4 

4 

3 

3 

VOICE  INPUT  QUERY  LANGUAGE 

2 

2 

2 

2 

2 

2 

2 

I 

2 

3 

1 

2 

3 

4 

3 

3 

VOICE  INPUT  NATURAL  LANGUAGE 

3 

3 

3 

3 

2 

3 

3 

3 

3 

2 

2 

2 

2 

4 

3 

3 

CURSOR  CONTROL  DIALOG 

2 

2 

1 

2 

1 

' 

I 

3 

3 

3 

3 

3 

3 

1 

I 

I 

QUESTION  (  ANSWER  0IAL0G 

2 

2 

2 

3 

2 

3 

3 

4 

3 

2 

2 

2 

4 

4 

3 

3 

QUERY  COMMAND  FILE 

I 

2 

3 

3 

2 

2 

2 

1 

2 

2 

2 

2 

2 

1 

2 

3 

QUERY  COttUKO  MACRO 

\ 

2 

3 

3 

2 

2 

2 

1 

2 

2 

2 

2 

2 

I 

2 

3 

*  Recommended  as  1st  choice  for  standardization  purposes. 


g.  Do  not  permit  deletion/alteration  of  data  item?;  by  direct 
command  entries  without  first  displaying  the  value  to  be 
deleted/altered. 

h.  Permit  the  user  to  request  "HELP"  as  necessary  to  determine 
required  parameters  in  a  command  entry,  or  to  determine 
available  options  for  an  appropriate  next  command  entry. 

i.  When  user/operator  computer  dialog  involves  prompting,  prompt 
data  entries  explicitly,  by  displaying  data  field  labels  and/ 
or  associated  user/operator  guidance  messages. 

j.  When  useful  default  values  cannot  be  predicted  in  advance, 
provide  a  capability  for  authorized  personnel  to  use  a  special 
transaction  to  define,  change  or  delete  default  values  for 
each  data  field. 


k.  Provide  the  capability  for  the  user/operator  to  change  a 
computer-generated  data  value.  However,  before  permitting 
the  value  actually  to  be  changed,  display  the  basis  for  the 
computer  calculations. 
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Do  not  force  the  user/operator  to  press  more  than  one  fixed 
function  key  (e.g.,  SHIFT  or  ENABLE  plus  the  function  key) 
to  perform  a  simple  operation. 

EXCEPTION;  If  unintentional  activation  of  a  fixed  function 
key  would  have  serious  consequences  for  system  operations 
or  system  output,  do  require  the  user/operator  to  press 
two  keys  simultaneously  to  activate  that  function. 


I 


1 
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5.1.6  ADVISORY  COMMENTS  FOR  QUERY  METHODS 


a.  User-initiated  query  language  dialog 

1.  Make  terms,  codes,  etc.  in  query  languages  consistent 
with  those  used  in  the  overall  control  method  for  the 
system. 

b.  Natural  language  dialog 

1.  Where  some  sophisticated  users  will  use  a  system  with 
natural  language  dialog,  provide  for  command  codes  and 
abbreviations  as  an  option  to  natural  language  interaction. 


c .  Menu  selection 


1.  Word  menu  options  so  as  to  permit  direct  selection  of  any 
option  as  an  acceptable  contol  input,  either  by  pointing 

or  by  code  entry.  Do  not  word  menu  options  so  as  to  imply  a 
question  requiring  a  YES/NO  answer. 

2.  If  menu  selection  is  used  in  conjunction  with  or  as  an 
alternative  to  query  language,  then  display  selected 
query  options  until  the  user  signals  entry  of  a  com¬ 
pletely  composed  command. 


3.  Display  menu  options  in  a  logical  order;  if  no  logical 
structure  exists,  then  display  options  in  order  of 
their  expected  frequency  of  use,  with  the  most  frequent 
listed  first. 

4.  In  a  displayed  menu,  include  only  those  options  appropriate 
at  that  particular  step  in  a  transaction  sequence,  and 

for  the  particular  user. 


5.  If  possible,  in  a  displayed  menu  include  all  query  options 

appropriate  at  that  particular  step  in  a  transaction  sequence. 

EXCEPTION:  A  familiar  set  of  general  control  options  always 
available  may  be  omitted  from  individual  displays;  it 
should  be  available  on  demand,  however. 


6.  When  option  selections  must  be  made  from  a  long  list, 
and  not  all  options  can  be  displayed  at  once,  provide  a 
hierarchic  sequence  of  menu  selections  rather  than  one 
long  multi-page  menu. 


EXCEPTION:  where  a  long  list  is  already  structured  for 
other  purposes,  such  as  a  list  of  customers,  a  parts 
inventory,  a  file  directory,  etc.,  it  might  be  reason¬ 
able  to  require  the  user  to  scan  multiple  display  pages 
to  find  a  particular  item.  Even  in  such  cases,  however, 
an  imposed  structure  for  sequential  access  may  prove 
more  efficient. 
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COMMENT:  Multi-page  option  lists  will  generally  hinder  learn¬ 
ing  and  use.  The  software  designer  can  usually  devise  sane 
means  of  logical  segmentation  to  permit  several  sequential 
selections  among  few  alternatives  instead  of  a  single  dif- 
ficult  selection  among  many. 

7.  When  the  user  must  step  through  a  sequence  of  menus  to  make  a 
selection,  design  the  hierarchic  structure,  insofar  as  possible 
within  the  constraints  of  display  space,  to  minimize  the 

n umbel,  of  steps  required. 

8.  when  hierarchical  menus  are  provided,  design  them  to  permit 
the  user  immediate  access  to  critical  or  frequently  selected 
options. 

9.  If  letter  codes  are  used  to  make  menu  selections,  then  insofar 
as  possible,  use  those  codes  consistently  in  designating  options 
at  different  steps  in  a  transaction  sequence. 

EXAMPLE:  Do  not  give  the  same  action  different  names  and 
hence  different  codes  (F=FORWARD  and  N=NEXT) j  do  not  give  the 
same  code  to  different  actions  (Q=QUIT  and  Q=QUEUE) . 

10.  Always  make  an  initial  menu  of  control  options  available  for 
user  selection,  to  serve  as  a  "home  base"  or  consistent  start¬ 
ing  point  for  control  inputs  at  the  beginning  of  a  transaction 
sequence . 

COMMENT:  Such  a  starting  point  is  helpful  even  when  all 
dialog  is  user- initiated.  This  capability  can  be  implemented 
as  an  OPTIONS  function  key,  as  an  explicit  control  option 
on  every  display,  as  a  generally  available  implicit  option, 
or  as  a  consistent  default  for  a  null  control  input. 

11.  Use  menu  selection  for  routine  tasks  with  fixed  procedures 
requiring  only  minimal  entry  of  arbitrary  data . 

12.  Do  not  use  menu  selection  dialog  when  the  transmission  rate 
will  be  less  tha  1 200  baud.  Relatively  fast  computer  response 
time  is  required  for  menu  selection  dialogs  because  the  menu 
options  must  be  transmitted  and  displayed  for  each  selection. 

13.  When  menu  selection  is  used  to  train  novices  to  use  a  command 
language,  make  the  wording  and  order  consistent  with  the  command 
language . 

14.  if  the  selection  list  exceeds  10-15  items,  reorganize  the  list 
into  two  separate  menu  frames,  maintaining  the  logical  organi¬ 
zation  within  the  hierarchy. 

15.  if  selection  items  have  been  grouped,  label  each  group. 
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Voice  input  natural  language 


1.  Use  voice  input  where  the  user's/operatbr 's  hands  and  eyes  are 
already  being  used  extensively  in  other  system  operations. 


2.  Limit  the  use  of  voice  input  to  situations  where  the  ambient 
noise  level  is  less  than  90  dba. 


Cursor  control  dialog 


1.  When  selection  among  displayed  query  options  is  to  be  accom¬ 
plished,  place  the  cursor  automatically  on  the  most  likely 
options  at  initial  display  generation. 


2.  Accomplish  designation  on  an  electronic  display  by  means  of  a 
movable  cursor  with  distinctive  visual  features  (shape,  blink, 
etc. ) . 


3.  Design  the  cursor  so  that  it  does  not  obscure  any  other  character 
displayed  in  the  position  designated  by  the  cursor. 


4.  Where  the  "targets"  for  the  cursor  are  arranged  in  rows  or  col- 
ulms,  design  the  cursor  interaction  such  that  the  cursor  can 
move  only  along  the  row  or  column  in  which  the  "targets"  appear. 
That  is,  do  not  allow  the  cursor  to  move  into  horizontal  areas 
where  no  target  apears. 


5.  When  position  designation  is  combined  with  keyed  data  entry, 
control  cursor  movement  at  the  keyboard  (by  function  keys, 
joystick,  etc.),  rather  than  by  a  separately  manipulated  device 
(light  pen,  "mouse,"  etc.). 

6.  Automatically  skip  the  cursor  past  any  data  field  filled  by 
computer-generated  data. 

7.  Use  cursor  control  dialog  when  conceptualizing  or  designing 
systems  which  have  interactive  graphics  as  their  primary  purpose, 
but  which  must  also  use  alphanumeric  menu  presentation  in  some 
processing  steps. 

8.  Avoid  using  cursor  control  dialog  when  the  users/operators  of 
the  system  will  have  no  need  to  control  the  position  of  the 
cursor  on  the  CRT  screen  other  than  to  select  items  from  an 
alphanumeric  command  menu  or  list. 

9.  Use  the  same  method  for  cursor  control  dialog  as  is  used  for 
graphics  interaction. 

10.  When  using  cursor  control  dialog,  make  the  "target"  for  the 
cursor  at  least  10  times  the  size  of  the  positioning  accuracy 
required  for  interactive  graphics  or  1/4"  square,  whichever  is 
smaller. 
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11.  Provide  feedback  to  the  user/operator  on  which  "target"  has  been 
selected  by  cursor  control  dialog.  Making  the  selected  target 
brighter  is  the  preferred  method. 

h.  Question  and  answer  dialog 

1.  Use  question  and  answer  dialog  for  routine  query  tasks,  where 
data  items  are  known  and  their  ordering  can  be  prespecified, 
where  the  user  will  have  little  or  no  training,  and  where  com¬ 
puter  response  is  expected  to  be  moderately  fast. 

2.  Brief  question  and  answer  sequences  can  be  used  to  supplement 
other  dialog  types  for  special  purposes,  such  as  for  log  on 
routines,  or  for  resolving  ambiguous  control  inputs  or  data 
entries. 

3.  Use  question  and  answer  dialogs  only  when  the  users/operators 
are  likely  to  be  very  unsophisticated  in  using  system  capabi¬ 
lities. 

4.  Use  question  and  answer  dialogs  when  the  users/operators  are 
required  to  provide  only  "YES"  or  "NO"  answers  to  questions 
about  desired  query  results. 

5.  Use  question  and  answer  dialogs  when  the  user/operator  is 
required  to  enter  information  which  cannot  be  placed  on  a 
list  or  easily  encoded  (e.g.,  time  other  than  current  time; 
number  of  troops) . 

6.  When  using  question  and  answer  dialogs,  provide  examples  of 
required  query  format  and  content  whenever  possible. 

i.  Query  command  file 

1.  Use  query  command  files  where  complex  data  retrieval  and 
manipulation  constitute  the  majority  of  the  operator's  work¬ 
load. 

2. 

Use  query  command  files  where  retrieval  can  be  complex  but 
results  in  substantially  the  same  format. 


j .  Query  command  macro 


1,  Use  query  command  macros  when  data  retrievals  and  manipulations 
are  complex  but  have  many  stable  parameters. 

2.  Use  query  command  macros  when  separate  data  retrievals  and 
manipulations  involve  the  same  data  and  similar  processing. 


3.  Use  query  command  macros  when  separate  data  retrievals  and 

manipulations  involve  the  same  processing  with  different  data. 
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Allow  the  user/operator  to  construct  query  command  macros  which 
can  query  the  user/operator  for  parameters  whose  values  change 
over  time. 

Display  the  current  value  of  any  control  parameter (s)  currently 
operative  for  user  reference. 

COMMENT:  This  practice  is  helpful  even  when  all  parameters  are 
user-selected  since  the  user  may  well  forget  them,  particularly 
if  task  activities  are  interrupted. 


5.2.1  DEFINITION 

Query  structure  refers  to  the  ways  in  which  the  user  may  organize  requests 
for  information.  It  deals  with  issues  such  as:  the  legal  sequences  of  query 
elements?  the  use  of  delimiters  between  elements;  and  the  ways  in  which  the 
user  may  indicate/select  options  in  query  specification. 


5.2.2  APPLICATIONS  FOR  QUERY  STRUCTURE 


Query  structure  is  applicable  wherever  the  user/operator  must  interact 
with  stored  or  data  base  information  to  retrieve  data.  Query  structure 

* 

influences  the  query  method  to  be  employed  and,  thus,  is  applicable  in  the 
user's/operator's  choice  of  technique  in  accessing  the  system.  Query 
structure  can  be  delineated  by  four  different  degrees  of  complexity: 

Simple,  Moderate,  Complex,  and  Extreme.  * 

a.  h  SIMPLE  query  structure  represents  the  least  complex  data 
retrieval  type.  It  contains  a  single  data  item  or  single 
parameter.  This  structure  is  one  most  easily  formulated 
and  is  linked  to  a  wide  variety  of  query  methods. 

EXAMPLE:  An  item  of  information  that  might  be  required 
by  the  Commander  is  the  number  of  tanks  available.  In  a 
Command  and  Control  battlefield  automated  system,  the  user/ 
operator  might  translate  the  Commanders 1 s  requirement  as 
follows: 

DIS (play)  ft  TANKS 

b.  A  MODERATE  query  structure  exhibits  an  average  degree  of 
complexity  in  retrieval  requirements.  This  structural  type 
is  composed  of  two  to  three  parameters  or  data  items. 

EXAMPLE:  The  user/operator  may  be  required  to  retrieve 
information  regarding  availability  of  gun  tubes  on  H60A1 
tanks  at  supply  points  within  a  50  mile  radius.  This  re¬ 
quest  may  be  interpreted  as  follows: 

PR(int)  TANK,  TUBE,  AREA  =  WHISKEY 
where  WHISKEY  is  a  code  descriptor  for, a  range  of  50  miles  radius. 


c.  A  COMPLEX  query  structure  is  composed  of  four  to  five  param¬ 
eters  or  data  items.  As  a  result  of  the  increased  number  of 

required  interrelated  items  of  information,  this  query  type  .  1 
imposes  a  higher  degree  of  complexity  whereby  construction  j 
becomes  more  complicated. 

EXAMPLE :  In  planning  for  a  forthcoming  operation,  the  Com-  .1 
wander  desires  to  know  how  many  rounds  of  HE  could  be  deliv-  i 
ered  to  the  3"  batteries  located  within  a  specified  area  ; 
within  the  period  from  H  to  ft  *  2  hours  from  a  designated  * 
ammo  supply  point.  The  user /operator  of  a  particular  command  * 
and  control  battlefield  automated  system  might  translate  the  * 
Commander's  requirement  as  follows: 


r 

Pft(tnt) 

AATY  •  8; 

«(1nt) 

type  •  «; 

«(1nt) 

IOC  ■  TANGO; 

PR(lnt) 

TIIC  •  H.  H  ♦  2; 

PA(lftt) 

SUP  -  ALPHA: 

EX(«euU) 

L. 

l 

where  TANGO  is  a  code  descriptor  for  the  Commander's  specified  area. 

d.  An  EXTREME  query  structure  represents  the  most  difficult  data 
retrieval  type  to  formulate.  It  consists  of  more  than  five 
parameters  or  data  items  and  is  aligned  with  a  limited  number 
of  query  methods. 

EXAMPLE:  A  Commander  of  Armor  Division  has  received  a  mission. 
During  his  planning,  he  must  know  how  many  armor  personnel 
replacements  will  be  available  for  assignment  to  tanks  prior 
to  H  -  10  hours.  If  this  number  will  be  less  than  75*  of 
authorized  strength,  then  he  must  find  out  how  many  personnel 
in  the  division  have  secondary  armor  MOSs  and  primary  MQSs 
that  will  not  be  critically  needed  during  the  operation.  The 
user/operator  of  a  wartime  personnel  accounting  system  might 
use  a  preformatted  “Pill-in-the-aianks"  input  display  to  trans¬ 
late  the  Commander's  requirement. 
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5.2.3  BENEFITS  OF  QUERY  STRUCTURE 


The  benefits  which  evolve  from  the  use  of  query  structures  include  the 
following: 

a.  Reduced  error  rates,  by  minimizing: 

1.  Errors  in  data  retrieval  by  operators  of  all  skill  levels. 

2.  The  number  and  difficulty  of  steps  required  to  retrieve 
stored  or  filed  data. 

b.  Increased  system  throughput  rates,  by  minimizing: 

1.  The  time  required  for  access  to  required  information. 

2.  The  time  required  for  utilization  of  data  base  information. 

c.  Increased  training  effects,  such  that: 

1.  Minimally  trained  operators  can  perform  the  simple  queries 
with  acceptable  facility. 

2.  Reduced  complexity  of  training  instructors  and  manuals  for 
the  query  process  can  be  achieved. 


Fill-in— bhe-blanks ,  in  which  the  user/operator  fills  out  a 
form  or  questionnaire  presented  at  the  terminal.  The  entries 
in  the  "blanks"  may  be  words,  codes,  numbers,  or  merely  sym¬ 
bols  ("checkmarks"  or  "Xs" )  to  indicate  that  the  user/operator 
wishes  to  perform  the  operation  displayed  on  the  "form. " 


«£«  COOt  MMU; _ 10 

CMMCC  coot: _ .  _  „  t  m  _  #»U  rill  OBIUD: _ 

ACTIVITY:  Kmil£IUU.:_  t0]T!«C:_ 

WTlOtS: _ _ 


Voice  input  natural  language,  which  is  typically  a  form  of 
user- initiated  query  language,  where  the  user/operator  speaks 
commands  instead  of  typing  them. 


1 


Query  command  file,  which  is  typically  user-built  and  initi¬ 
ated.  The  user/operator  supplies  some  prompted  information 
and  then  runs  the  file. 


j .  Query  command  macro,  relatively  permanent  routings  initi¬ 
ated  by  the  user/operator  who  supplies  prompted  parameters. 


Quar  MCAO:  AIT;  STATUS,  K,  At,  MUMS 
AITtUCM  IATTAU«(S)T 

AUTUUAT  lATTALItK(S) _ T 

AITIUIM  lATTAUM(S) _ T 

AATIUiAT  lATTAUQttS) _ T 
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5.2.5  RECOMMENDATIONS  FOR  QUERY  STRUCTURE 

a.  Table  5.2-1,  Query  Method  by  Complexity  of  Query  Structure 

Type/  presents  a  general  list  of  recommendations  for  selecting 
the  most  effective  query  method  or  methods  given  the  complexity 
of  the  query  structure  type.  Before  making  a  final  decision, 
consult  specific  recommendations  for  individual  query  structures 
in  Section  5.2.6. 
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To  use  the  table,  first  decide  what  query  structure  (according 
to  number  of  parameters)  applies  to  the  situation  you  are  con¬ 
sidering.  Eliminate  any  query  method  where  a  "4"  appears  as 
an  entry.  Select  the  best  query  method  by  comparing  the  remain- 
ing  types  in  view  of  the  query  structure  you  are  formulating. 

Table  5.2-1.  Query  Method  Hy  Complexity  of  Query  Structure  Type 


KEY: 

1  -  RECOMMENDED 

2  -  ACCEPTABLE 

3  -  WORKABLE  BUT  SUBOPTItlAL 

4  -  NOT  R£C0! MENDED  OR  NOT  APPLICABLE 

QUERY  STRUCTURE  (NUMBER  OF  PARAMETERS)  j 

SIMPLE 

(1) 

MODERATE 

(2-3) 

COMPLEX 

(4-5) 

EXTREME 

(5+) 

QUERY  LANGUAGE  DIALOG 

1* 

1* 

1 

1 

NATURAL  LANGUAGE 

1 

1 

1 

1 

MENUS 

1 

2 

i 

4 

FILL  IN  THE  BLANKS 

2 

2 

3 

3 

o 

o 

X 

VOICE  INPUT  QUERY  LANGUAGE 

1 

1 

2 

2 

t- 

X 

VOICE  INPUT  NATURAL  LANGUAGE 

1 

1 

2 

2 

CURSOR  CONTROL  DIALOG 

2 

3 

3 

4 

QUESTION  S  ANSWER  DIALOG 

1 

1 

2 

2 

QUERY  COWAND  FILE 

2 

2 

1* 

1 

QUERY  COMMAND  MACRO 

2 

2 

I 

1* 

*  Recoowended  as  1st  choice  for  standardization  purposes. 
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c. 


Provide  multiple  paths  through  a  transaction  to  accommodate 
experienced  as  well  as  inexperienced  users/operators.  For 
example,  in  a  menu-oriented  system,  allow  inexperienced  indi¬ 
viduals  to  work  through  a  sequence  one  menu  at  a  time. 

If  a  delimiter  is  required  to  distinguish  optional  parameters 
or  separate  keyed  entries  in  a  stacked  command,  use  a  standard 
symbol  for  that  purpose,  preferably  the  virgule  (/)  to  separate 
the  series  of  data  entries. 
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5.2.6  ADVISORY  COMMENTS  ON  QUERY  STRUCTURE 

The  methods  used  in  implementing  query  structures  are  the  same  methods 
used  in  determining  compatability  with  characteristics  of  the  system  or  system 
users.  These  methods  have  been  discussed  and  illustrated  in  Sections  5.1.4 
through  5.1.6  as  well  as  in  Sections  5.2.4  and  5.2.5.  Query  structure  has 
been  defined  as  relating  to  the  complexity  of  the  retrieval  order  itself  and 
the  suitability  of  the  order  with  any  of  the  query  methods  discussed.  The 
suitability  of  the  methods-structure  pairing  is  shown  in  Table  5.2-1,  Query 
Method  by  Complexity  of  Query  Structure  Type.  No  further  discussion  of 
methods  will  be  attempted  in  this  section;  however,  comments  pertaining  to 
the  structure  themselves  will  be  presented.  As  the  number  of  parameters 
required  to  effect  a  query  increases,  the  suitability  of  some  of  the  query 
methods  decreases.  Operability,  end  users,  and  the  mission  itself  will  all 
benefit,  therefore,  from  increased  time  and  effort  spent  to  reduce  the  number 
of  parameters  per  query.  Some  considerations  for  the  structuring  of  queries 
include : 

a.  Provide  parameter  values  that  do  not  exceed  5-7  characters. 

b.  If  parameter  values  can  be  abbreviated,  provide  abbreviations 
that  do  not  require  punctuation. 

c.  When  a  dimensional  unit  is  constantly  associated  with  a  partic¬ 
ular  entry  field,  display  the  unit  as  part  of  the  fixed  label 
rather  than  having  it  entered  by  the  user/operator. 

d.  Provide  parameters  whose  definition  is  understood  by  the  user/ 
operator,  not  just  the  programmer. 

e.  Use  special  function  keys  for  the  input  of  critical  parameters 
or  partial  parameter  strings. 

f.  Provide  common  language  nomenclature  for  parameter  values, 
especially  if  unsophisticated  users/operators  are  expected, 
due  to  high  turnover,  reassignment,  limited  training,  etc. 

g.  If  parameter  values  can  be  abbreviated,  permit  the  use  of  any 
unambiguous  abbreviation  for  the  value. 

h.  If  punctuation  is  required  to  separate  multiple  parameter  values, 
use  the  virgule  (/)  as  the  delimiter. 


i.  Provide  the  user/operator  with  the  option  of  selecting  default 
values  for  certain  parameter  strings. 


j.  When  multiple  parameters  are  entered  as  a  single  transaction, 
provide  the  user/operator  with  the  ability  to  restart,  cancel, 
or  change  any  item  before  taking  a  final  enter  action. 

k.  Provide  the  user/operator  with  a  dictionary  of  abbreviations 
and  codes,  available  on-line. 

l.  If  codes  are  a  necessary  part  of  the  parameter  values,  provide 
letter  codes  in  mnemonic  form  rather  than  numeric  codes. 


6.1.1  DEFINITION 


Symbols  are  single  alphabetic,  numeric,  graphic,  and  pictorial  elements; 
they  are  the  fundamental  units  that  users/operators  employ  to  construct  inputs 
to  battlefield  automated  systems,  and  that  systems  employ  to  construct  outputs 
to  users/operators.  Symbols  may  include  any  or  all  of  the  following: 

a.  Alphabetic  symbols,  comprising  the  26  roman  letters  "a"  through 
“z,"  used  in  either  upper  or  lower  case.  The  number  of  alphabetic 
elements  may  be  expanded  by  using  both  upper  and  lower  case,  and 
by  using  two  or  more  distinctive  type  fonts.  Other  letters  (e.g., 
Greek  or  Russian)  are  considered  to  be  special  symbols,  as  de¬ 
scribed  below.  Roman  numerals  are  a  special  case  drawn  from  the 
normal  roman  letters. 

b.  Arabic  symbols,  comprising  the  10  numerals  0  through  9. 

c.  Grammatical  symbols,  which  are  used  in  ordinary  printing  or 
writing,  such  as  (,),  (.),  (/) ,  {;),  and  (:). 

d.  Special  symbols,  comprising  the  signs  associated  with  various 
branches  of  science  and  technology.  Examples  of  special  symbols 
are  (a)  the  Greek  letter  "sigma"  used  in  statistics  to  denote 
the  population  standard  deviation;  (=0  to  mean  "equal  to"  in 
mathematics,  and  (=)  to  mean  a  “triple  bond"  or  “negative  charge" 
in  chemistry. 

c.  Graphic  symbols,  abstract  symbols  assigned  a  particular  meaning 
in  a  given  application,  (tifd)  used  to  denote  infantry  and  ((£*0) 
used  to  denote  armor  units  are  examples  of  graphic  symbols. 

Graphic  symbols  may  i«  accompanied  by  alphabetic  or  numeric 
symbols  for  amplification  (e.g.,  “xx“  atop  the  symbol  “  E3  “ 
denotes  an  armor  division,  as  opposed  to,  say,  a  corps  or 
brigade) . 

f,  pictorial  symbols,  representational  symbols  used  in  graphics 

displays.  Examples  of  pictorial  symbols  aro  {$•)  stick  figures 
used  in  a  histogram  (bar  chart)  to  represent  available  strength, 
or  (^jr3)  a  simplified  drawing  of  a  cannon  used  on  a  map  to 
depict  artillery  locations  or  strength. 

Symbol  sets  are  made  up  of  the  collection  of  symbols  available  in  a  given 
system  for  constructing  inputs  and  outputs. 


6.1.2  APPLICATIONS 


Each  of  the  general  types  of  symbols  is  used  for  a  somewhat  different 
purpose.  Often,  though  not  always,  this  utilization  is  obvious.  In  addition 
different  types  of  symbols  are  normally  combined  within  a  single  symbol  set. 
For  example,  the  standard  office  typewriter  and  many  computer  terminal  key¬ 
boards  contain  a  "standard"  alphanumeric  symbol  set  consisting  of  the  alpha¬ 
betic,  arabic,  and  grammatical  symbols,  plus  a  few  of  the  special  symbols 
(e.g. ,  @,  $,  *,  #) .  In  general,  symbol  types  are  utilized  as  follows: 

a.  Alphabetic  symbols  are  used  to  form  plain  language  words  (e.g., 
"soldier,"  "bridge,"  "tank,"  "carburetor");  abbreviations  (e.g., 
"Arty,"  "CPT , "  "Trk, "  "Div") ;  acronyms  (e.g.,  "BETA,"  "USAREUR," 
"FEBA") ;  and  some  types  of  codes  (e.g.,  "TACFIRE,"  "HHC , “  "ECM") . 

b.  Arabic  symbols  are  used  most  often  to  express  numerical  quan¬ 
tities  such  as  counts  or  distances.  Frequently,  they  are  also 
used  as  codes.  Telephone  numbers,  ZIP  codes,  equipment  designa¬ 
tors,  target  designators,  and  identifiers  for  menu  options  on 

a  display  are  examples. 

c.  Grammatical  symbols  are  normally  used  as  punctuation  in  plain 
language  text  portions  of  system  inputs  and  outputs.  They  are 
also  used  sometimes  as  field  and  subfield  delimiters  in  pre¬ 
formatted  displays.  For  example,  the  date  field  on  a  CRT 
might  be  displayed  as  “DATE:  11/16/81." 

d.  Special  symbols  are  used  to  indicate  mathematical  relationships 
or  other  forms  of  "shorthand."  For  example,  a  request  to  show 
all  battalion-level  units  that  currently  are  less  than  80%  of 
authorized  personnel  strength  might  be  expressed  as  "SHOW 

BN  <  80%  PERS • " 

o.  Graphic  symbols  are  used  to  represent  objects  or  quantities  when 
precise  detail  is  not  required  and  the  symbols  will  conserve 
space,  add  meaning,  or  speed  interpretation  of  a  display.  For 
example,  on  a  map  display  the  symbol  "(2]  “  conveys  the  loca¬ 
tion  of  an  armor  division  at  a  glance,  though  it  provides  no 
detail  such  as  strength  or  fuel  status. 

f.  pictorial  symbols  serve  much  the  same  purposes  as  graphic  symbols. 
However,  they  generally  are  less  abstract  and  therefore  less 
ambiguous  than  graphic  symbols.  Pictorial  symbols  are  conse¬ 
quently  more  appropriate  for  naive  users/operators  in  situations 
that  do  not  require  detail  or  precision  than  for  experienced 
users/operators  who  do  not  need  so  much  detail. 
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6.1.3  BENEFITS 


The  initial  benefit  of  symbols  and  symbol  sets,  of  course,  is  that  they 
enable  communication  between  users/operators  and  battlefield  automated 
systems.  Careful  selection  of  symbols  and  symbol  sets  provides  additional 
benefits,  including: 


a. 


Efficient  intrasystem  and  intersystem  communication  through 
reduction  of  need  for  routines  to  translate  the  symbols  of 
one  workstation  or  system  to  that  of  another  workstation  or 
system . 


b. 


Reduced  time  required  for  users/operators  to  c  mplete  trans¬ 
actions  with  the  system,  thereby  reducing  throughput  time. 


c. 


Reduced  user/operator  error  rates,  thereby  reducing  contamina¬ 
tion  of  data  bases  and  erroneous  products;  also  contributes 
to  reduced  throughput  time  by  reducing  error  detection,  diag¬ 
nostic,  and  correction  procedures. 
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6.1.4  METHODS 

Methods  which  can  be  used  for  selection  of  symbols  and  symbol  sets  include: 

a.  Use  of  standard  terminal  keyboards  which  provide  the  standard 
alpha  and  numeric  symbols  and  the  more  usual  grammatical  sym¬ 
bols.  These  keyboards  can  frequently  accommodate  a  few  special 
symbols.  Utilization  of  common  terminals  across  system  posi¬ 
tions  and  across  systems  provides  terminals  with  identical 
symbol  sets.  Even  when  different  terminals  ere  used,  terminals 
with  consistent  symbol  sets  can  be  selected. 

b.  Use  of  off-the-shelf  keyboards  which  permit  incorporation  of 
additional  grammatical  symbols,  special  symbols,  and  graphic 
symbols . 

c.  Software  can  be  used  to  generate  symbol  sets.  For  example, 
software  is  frequently  used  to  define  map  symbology  in  auto¬ 
mated  cartographic  applications. 

d.  Users/operators  may  be  required  to  generate  graphic  symbols 
on  terminals  which  allow  this,  e.g.,  in  interactive  computer 
graphics  applications. 


PURPOSE /TASK 


5.1.5  RECOMMENDATIONS  FOR  SYMBOLS  AND  SYMBOL  SETS 


6. 1,5.1  Selection  of  Symbol  Sets 

a.  Selection  of  symbols  and  symbol  sets  is  dependent  upon  the  type 
of  usage  intended  and  the  variability  of  that  usage.  The  selected 
symbol  set  must  be  adequate  to  fulfill — but  not  exceed — the  most 
complicated/sophisticated  usage  required.  Table  6.1-1  provides 
guidance  on  the  types  of  symbol  sets  required  for  different  task 
requirements.  As  these  requirements  become  more  diversified  at 
a  given  user/operator  position,  the  symbol  set  requirement  may 
become  more  diversified.  If,  for  example,  the  user/operator  uses 
a  menu  from  which  to  select  a  special  technical  content  report 
format,  display  of  the  menu  makes  provision  of  the  upper  case 
alpha  symbol  set  mandatory  and,  depending  upon  requirements,  may 
not  make  the  numeric  symbol  set  necessary.  By  calling  up  the 
special  technical  report  format,  any  of  a  number  of  symbol  sets 
may  or  may  not  be  required  (lower-case  alpha,  numeric,  standard 
grammatical,  nonstandard  grammatical) ,  but  the  set  of  special 
symbols  appropriate  to  the  technical  area  would  be  required. 


Table  6.1-1.  Types  of  Symbols  Required  by  Application 


1  «  acquired 

}  •  Probably  required 

3  •  Koet  probably  not  required 

SYMBOLS  PROVIDED  3Y  KEYBOARD 

GRAPHIC 

SYMBOL 

GENERATION 

CAPABILITY 

UPPER 

CASE 

ALPHA 

LOWER 

CASE 

ALPHA 

NUMERIC 

STANDARD 

GRAMMATICAL 

NONSTANDARD 

GRAMMATICAL 

SPECIAL 

TECHNICAL 

PURPOSE 

Mam*  Itu  Diaplay /Select ion 

■ 

B 

2 

2 

i 

2 

2 

Query  Method* 

B 

B 

2 

2 

2 

2 

2 

rued  Poraat  Mptvajujeerlc 

Neataqe  oleplay/CoDpletlon 

1 

B 

1 

1 

2 

2 

2 

Variable  Tonal  Alphameric 
Ntiuqt  Oiaplay/Ccppletioo 

l 

B 

■1 

1 

2 

2 

2 

free  Teat  neaaaqe  (Depletion 

B 

B 

1 

» 

PM 

1 

Deport  oeneret  lon/Vle?ley 

m 

2 

1 

2 

Bi 

1 

Special  Technical  Cviteat 

Mport  CeftcreikcA/DlepMy 

1 

2 

7 

2 

| 

HI 

1 

Graphic  *******  Generation/ 

Map  lay 

2 

2 

m 

2 

■ 

Bi 

1 

Special  Technical  Graphic 

Naa**t*  DieplayAVeMtat  4c« 

1 

_ 

2 

. 

2 

■1 

B 

1 
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b.  When  alphabetic  data  entry  is  required,  restricted  alphabetic 
symbol  sets  should  not  be  used. 

c.  When  special  characters  are  used  (@,  *,  +,  #,  etc.)  particularly 
if  they  are  used  frequently,  they  should  be  chosen,  to  the  extent 
possible,  to  avoid  shifting  from  one  case  to  another  on  the  key¬ 
board. 


6. 1.5. 2  Symbology  Definitions 

a.  When  symbols  are  used  separately  or  in  text,  they  should  have  a 
specific  definition  suited  to  that  application.  Grammatical  and 
other  symbols  retain  a  meaning  acquired  through  standard  usage, 
i.e.,  a  "population  stereotype."  When  these  symbols  are  incor¬ 
porated  into  the  user-computer  interface  language,  meanings 
acquired  in  other  usage  should  be  considered  and  retained  to  the 
extent  possible. 


b.  If  a  choice  of  symbols  is  available,  use  the  simplest  one  possible. 
Take  into  consideration  the  following  aspects: 
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Table  6.1-2.  Generally  Accepted  Usages  for  Standard  Symbols 


RECOMMENDED  USE P-COKPuTE  P  INTERFACE  USAGE  ! 

S1H80L 

LABEL 

CONVENTIONAL  USAGE 

FIXED  rORMAT  MESSAGE 

MATHEMATICAL  APPLICATION 

Period 

At  the  end  of  a  declarative 
sentence;  following  an  abbre¬ 
viation;  before  a  decimal , 
between  dollars  and  cents. 

Not  recommended  for  use. 

Use  in  convenLional  sense, 

1  .e. ,  before  a  decimal , 
between  dollars  and  cents. 

' 

Comma 

Sets  off  a  phrase;  separates 
word  series  and  phrase  series, 
separates  numbers  In  dates, 
as  in  January  24,  1982, 

Use  as  a  multi-valued  field 
delimiter  to  separate  indi¬ 
vidual  and  comparable 
entries. 

Use  to  separate  series  of 
numbers 

/ 

Virgule 
or  slash 

Separates  alternatives,  as  in 
and/or;  used  to  represent 
"per"  as  In  miles/hour. 

Use  ts  within  field  delimi¬ 
ter  of  separate  individual 
but  different  entries. 

Use  as  an  arithmetic  opera¬ 
tor  to  indicate  division. 

Colon 

When  the  colon  follows  a  word 
it  introduces  a  Quotation,  an 
explanation,  an  example,  or  a 
series  of  things;  used  be- 
tween  numbers  in  expressions 
of  time  (02:30)  or  to  express 
ratios  (2:1). 

Use  in  time  entries  to  sep¬ 
arate  2-digit  indications 
of  hour,  minutes,  seconds; 
(08:30  10). 

Use  to  Indicate  ratios. 

Semi- 

colon 

Used  to  separate  parallel 
expressions;  separates  suc¬ 
cessive  phrase  elements;  acts 
as  a  strong  comma  or  a  weak 
period. 

Use  as  the  end  of  a  data 
field  delimiter. 

Not  recomended  for  use. 

0*$h  or 
ntftul 

Sets  off  a  paranthetlcal 
clause;  Indicates  an  omis¬ 
sion,  indicates  a  break  in 
thought;  indicates  a  subtrac¬ 
tion;  indicates  a  negative 
value  (e.g. ,  -15*F). 

Use  to  indicate  spaces  not 
available  for  data  entry; 
use  to  indicate  negative 
values. 

Use  as  an  arithmetic  opera¬ 
tor  to  indicate  subtraction 

Plus 

Sign 

Indicates  an  addition;  indi¬ 
cates  a  positive  value  (e.g., 
*15*C) . 

Jse  to  indicate  positive 
values. 

Use  as  an  arithmetic  opera- 
tor  to  indicate  addition. 

• 

Oegree 

Sign 

Indica'.rs  a  unit  division  of 
a  temperature  scale;  indi¬ 
cates  a  unit  of  latitude  or 
longitude,  indicates  a  unit 
of  angular  Mature. 

Use  in  the  conventional 
sensti.  The  context  will 
make  the  meaning  clear. 

Not  applicable. 

— 

Undtr- 

Scort 

Sets  off  a  symbol  or  set  of 
symbols  and  Indicates  empha¬ 
sis. 

Use  to  indicate  spaces 
that  are  to  be  used  for 
data  entry. 

Not  recoanended  for  use. 

* 

Out** 

ttoft 

Uitd  *t  the  end  of  9  icnlcnct 
th*t  i»  4ft  iftvtltng 

a  reply. 

use  In  menu/Query  format 
to  indlcete  a  reply  is 
required. 

use  in  mathematical  expres¬ 
sions  to  Indicate  an  un¬ 
known  quantity. 

• 

asterisk 

Used  in  writing  io  indicate 
an  omission;  used  at  a  refe¬ 
rence  to  a  footnote. 

Use  to  set  of f/hlghl ighi 
data  entries. 

Use  it  an  arithmetic  opera- 
tor  to  indicate  »uHiplica- 
tiO". 

1 

tkcUkSS- 

tlO" 

point 

Used  after  an  e«elanalton, 
t.e.,  an  abrupt  utterance 
or  outcry,  following  a 
number,  indicates  the  fac¬ 
torial  of  that  number,  (the 
product  of  all  the  positive 
integers  froai  1  to  that  num¬ 
ber,  e.g..  4!  •  lajal«4*24!. 

vtt  lo  tftglutt  the  of 

use  «  maihemanca'  expres¬ 
sion  io  indicate  a  factcrwl 
number. 
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6. 1.5. 3  Symbol  DiscrimlnabiHty 

a.  The  recognizability  of  individual  symbols  is  affected  by  such 
factors  as  stroke  width,  slant,  brightness,  and  the  number  of 
symbols  displayed.  In  order  to  make  symbols  as  distinct  from 
each  other  as  possible,  the  design  of  individual  symbols  should 
attend  to  the  following: 

1.  Capital  letters  are  the  most  easily  recognized  individual 
symbols.  (Capital  letters  are  enormously  over learned  from 
early  childhood  on.) 

2.  Letters  such  as  A,  B,  E,  F,  P,  R,  should  have  a  clearly 
delineated  space  above  the  horizontal  stroke. 

3.  C  and  G  are  easily  confused  with  each  other  if  the  hori¬ 
zontal  stroke  on  the  G  is  not  long  enough. 

4.  D  and  O  are  easily  confused  unless  the  O  is  very  rounded 
and  the  D  is  somewhat  squared. 

5.  0  and  V  are  easily  confused  unless  the  U  is  squared  and  the 
bottom  angle  of  the  V  is  very  sharp.  A  long  vertical  cen¬ 
ter  stroke  on  the  Y  eliminates  confusion  between  Y  and  V. 

6.  Considerable  confusion  is  possible  between  "1“  (the  lower 
case  L) ,  the  upper  case  "I,"  the  number  "1,"  and  the 
number  "7."  A  numerical  configuration  such  as  shown  in 
Figure  6.1-1  can  overcome  most  of  these  problems,  espe¬ 
cially  when  a  segmented  numeral  configuration  is  possible. 


/  B  3  R  5  b  IBRD 

Figure  6.1-1.  Proposal  for  Improved  Seven-Segment  Elumeral  Configurations 


Note  that  tiro  above  numerals  incorporate  the  following  char¬ 
acteristics: 

(a)  A  slant  of  15  -  20  degrees,  clearly  distinguishing 
numbers  from  lotters  if  vertical  letters  are  used. 

(b)  Accentuation  (50%  increased  stroke  width)  of  some 
strokes  (the  loft  vertical  strokes  and  the  middle 
and  lower-horizontal  strokes) . 


•Van  Nes,  F.  L.  and  Bouraa,  H.  On  the  legibility  of  segmented  numerals. 
Human  Factors,  1980,  22(4),  463-474. 
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(c)  Increased  length  of  horizontal  segments  to  achieve 
a  height  to  width  ratio  of  1.5 si. 

b.  Slanting  of  numbers  {versus  vertical  letters)  eliminates  con¬ 
fusion  between  the  number  "5"  and  the  letter  "S"  and  between 
the  "1"  (the  lower  case  L)  and  the  number  "l,"  Unless  the  upper 
case  "I"  carries  the  top  and  bottom  serifs,  confusion  between 
the  “1"  (the  lower  case  L)  and  the  upper  case  "I"  will  be  sus¬ 
tained.  If  segmented/slanted  numbers  are  not  used,  the  follow¬ 
ing  constructions  will  help  to  eliminate  confusions: 

1.  I  =  the  number  "one" 

2.  ?  =  the  (European)  number  "seven" 

3.  1  =  the  lower  case  "L" 

4.  I  =  the  upper  case  "i" 

c.  Confusion  between  the  upper  case  "0"  and  the  "zero"  numeral 
can  be  eliminated  by  a  slant  through  the  zero: 

1.  0  =  the  letter  "0" 

2.  0  =  the  number  "zero" 


6. 1.5. 4  Type  Characteristics 

a.  In  general,  normal  type  fonts  available  on  standard  keyboards 
(typewriters,  for  example)  are  of  roughly  equivalent  legibility. 
Overly  ornate  fonts,  such  as  Old  English  (also  called  black  let¬ 
ter)  and  script,  should  be  avoided. 

b.  For  printed  material  to  be  viewed  at  comfortable  book  reading 
distances,  9-point  to  12-point  type  (.125  inch  to  .167  inch 
height)  is  best.  (Type  font  height  is  measured  by  the  height 
of  the  lower  case  'V  symbol.)  Larger  type  is  useful  for 
emphasis  or  when  distance  or  other  factors  present  perceptual 
problems . 

c.  For  noncontextual  searching  applications  on  a  CRT  display 
which  uses  stroke-generated  characters,  variations  of  character 
size  within  a  range  of  .12  to  .16  inch  are  appropriate.  (Note 
that  these  are  almost  identical  to  the  optimum  size  for  printed 
materials.)  If  space  on  the  screen  is  at  a  premium,  even 
smaller  size  type  (6. 6-point/. 09  inches)  is  adequately  legible. 

d.  The  optimum  height  of  letters  in  a  raster-type  CRT  display  is 
about  9  to  10  raster  lines.  Optimum  width  of  characters  is 
about  75  percent  of  character  height.  Optimum  character  height 
ratios  vary  with  the  figure-ground  contrast.  A  ratio  of  1:5 

to  1:10  is  appropriate  for  black  letters  on  an  illuminated 
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background;  1:8  to  1:10  is  appropriate  for  illuminated  letters 
on  a  dark  background;  and  1:12  to  1:20  is  appropriate  for  highly 
illuminated  letters. 

For  numerals,  optimum  character  height  to  stroke  width  ratios 
are  in  the  range  of  4:1  to  6:1  when  printed  materials  are  used. 
These  same  ratios  appear  to  be  appropriate  for  raster-type  CRT 
displays. 

When  a  large  amount  of  text  is  to  be  entered  or  read,  appropri¬ 
ately  intermixed  upper  and  lower  case  characters  are  easier  to 
read  than  all  upper  case  characters.  In  these  instances,  normal 
grammatical  construction  rules  are  to  be  followed  and  grammatical 
symbols  are  required,  as  well  as  both  upper-  and  lower-case 
alphabet  symbols.  In  some  cases,  however,  the  use  of  all  upper¬ 
case  letters  can  be  justified: 

1.  For  emphasis. 

2.  For  greater  legibility  at  distances. 

3.  To  display  key  alerting  words  or  phrases. 

4.  To  display  target  words  in  a  list  of  terms. 

5.  In  scanning  situations. 


6.2  Standard  Terms 


6.2.1  DEFINITION 

Standard  terms  are  those  full  word  conventions  which  provide  consistent 
terminology  to  be  employed  in  user/operator  interaction  with  the  system.  A 
subset  of  the  full  language  standard  terms  provides  terminology  appropriate 
to  a  given  area  of  science  or  technology.  They  may  be  "coined"  words  (such 
as  TACFIRE) ,  acronyms  (such  as  FEBA) ,  or  universally  accepted  codes  or 
abbreviations  (such  as  Hz  for  hertz),  use  of  which  is  so  frequent  and  so 
conventional  in  a  given  context  as  to  render  them  as  well  known  and  under¬ 
stood  to  their  user  population  as  full  language.  This  complete  absorption 
into  their  users'  vocabulary  is  one  characteristic  that  distinguishes  these 
terms  from  codes  and  abbreviations.  (See  Section  6.3,  Abbreviations  and 
Codes . ) 
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6.2.2  APPLICATIONS  OF  STANDARD  TERMS 

Standard  terms  may  be  used  as: 

a.  Commands  input  to  the  system  by  the  user/operator  to  control 
the  system  (as  described  in  Section  1.1,  Alphanumeric  Control 
Methods) . 

b.  Menu  items  presented  by  the  system  to  guide  the  user/operator 
in  interacting  with  the  system  (as  described  in  Section  1.3, 
helps) . 

c.  Text  content  to  fill  message  formats  (as  described  in  Sec¬ 
tion  2.1,  Alphanumeric  Displays). 

Specific  applications  for  standard  terms  include: 

a.  To  provide  terminological  consistency  within  a  given  system 
for: 

1.  Within-process  sequences. 

2.  Across-process  sequences. 

3.  Hard  copy  input/output  information. 

b.  To  provide  terminological  consistency  across  systems  for  such 
information  as: 

1.  Equipment  descriptions  and  designators. 

2.  Place  names. 

3.  Organizational  descriptions. 

4.  Echelon  descriptions. 

5.  Units  of  measure. 
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6.2.4  METHODS 


Methods  which  can  be  used  for  assuring  utilization  of  standard  terms 
include: 

a.  Reference  to  off-line  sources  of  standard  terms  appropriate  to 
the  context.  (See  Section  6.5,  Glossaries.) 

b.  On-line  presentation  of  appropriate  terminology  from  which  the 
user/operator  selects  the  appropriate  term.  Such  presentation 
usually  is  in  the  form  of  a  menu. 

c.  Implementation  of  evident  and  workable  rules  and  procedures 
for  generation  and  dissemination  of  system-unique  terminology. 

d.  Built-in  system  checks  which  identify  illegal  entries.  (See 
also  Section  3.1,  Information  on  Legal  Entries  and  Section  7 
on  ERROR  HANDLING.) 
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6.2.5  RECOMMENDATIONS  FOR  STANDARD  TERMS 


6. 2. 5.1  Term  Selection 

a.  Select  terms  carefully  and  in  a  consistent  fashion  to  assist  the 
user's  task  and  to  support  training.  For  example,  when  dealing 
with  "minimum"  and  "maximum"  concepts,  standard  usage  of  "MIN" 
and  "MAX"  communicates  clearly,  consistently,  and  concisely. 

b.  Use  shorter  rather  than  longer  terms  if  there  is  a  choice. 

Strive  for  a  limit  of  5  -  7  characters  per  word.  Errors 
increase  with  longer  words. 

c.  Take  advantage  of  the  hierarchical  structure  of  language.  For 
example: 


TERRAIN 

NATURAL  FEATURES 
Cave 

Depression 

Hilltop 

Lake 

Marsh/swamp 

Ridge 

River 

Stream/creek 

Valley 

MAN-MADE  FEATURES 
Cemetery 

Crossing,  railroad 
Crossing,  river 
Junction,  railroad 
Junction,  trail 
Railroad  track 
Road 
Trail 

d.  Avoid  difficult  terms  that  arc  not  commonly  used  by  all  users. 
Choose  terms  (for  example,  for  command  language  or  for  data 
entry)  that  refloct  the  user's  point  of  view  and  not  the  pro¬ 
grammer’s.  A  basic  rule  for  programmers  and  system  designers 
should  be:  Know  the  users  and  adapt  terminology  to  their 
vocabulary  ins toad  of  vice  versa. 


e.  When  Army  "doctrine"  provides  terms  appropriate  to  a  given 
context,  incorporate  those  terms  into  the  usage  context.  In 
the  event  of  doctrine  usage,  provide  a  way  to  integrate  new 
doctrinal  terms  into  system  usage  as  these  become  available 
or  to  reflect  changes  in  doctrinal  terminology  as  those  are 
made. 
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f.  Select  terms  that  have  intrinsic  meaning  to  the  user.  For 

example,  military  time  is  expressed  in  terms  of  a  24-hour  clock 
rather  than  by  two  12-hour  clocks. 

6.2. 5.2  Term  Usage 

a.  All  terms  should  be  used  consistently  and  should  be  standardized 
in  meaning  from  one  transaction  to  another,  one  task  to  another, 
and — to  the  extent  possible — one  context  to  another.  For  example, 
do  not  use  EDIT,  MODIFY,  and  UPDATE  interchangeably.  If  all  are 
to  be  used,  make  sure  their  usage  is  distinct  and  clearly  defined 
to  the  user.  (See  Section  6.5.5,  RECOMMENDATIONS  FOR  GLOSSARIES 
for  examples  of  specific  distinctions  among  sample  command  terns.) 

b.  Use  as  few  terms  as  possible.  Avoid  special  terms  for  special 
cases  if  more  general  terms  will  suffice. 

c.  When  usage  is  common  to  two  or  more  presentations,  maintain  con¬ 
sistent  and  uniform  wording.  A  display  called  up  by  selection 
of  a  menu  option  should  maintain  the  wording  of  the  menu  option 
in  the  title  of  the  display.  For  example : 

_ USE  _  DO  NOT  USE 


r  “> 

IN  WHAT  TYPE  OF  EQUIPMENT  ARE  YOU  INTERESTED? 

III  IRUT  TYPE  OF  EQUIPMENT  ARE  YOU  INTERESTED? 

1.  CO  —  COMBAT  EQUIPMENT 

J.  CO  "■  CQWAT  EQUIPttNT 

2.  AI  —  AIR  EQUIPKNT 

2.  At  —  AIR  EQUIP*NT 

1.  TR  —  TRANSPORTATION  EQUIPMENT 

J.  TR  ~  TRANSPORTATION  EQUIPMENT 

4.  EM  —  ENGINEERING  EQUIPMENT 

4.  EH  —  ENGINEERING  EQUiPttMT 

S.  *lc. 

S.  *tc. 

~»  CQ 

-»  CO 

V _  _ J 

w.  -  .  - .  ..  H 

f  ^ 

>-  T'^ 

IN  WHAT  TYPE  OF  CGP*AT  EQUIPMENT  ARE  YOU  INTESESTEO? 

IN  MUCH  Of  the  FQUQMtRG  ARE  YOU  I»tE*ES?IO? 

1 .  m  —  AIKWUC  EQUIPMENT 

I  ASM  —  ASiOREO  t/UlPMENT 

OC  ...  COMMAND  AND  CONTWX  EQUIPTW? 

2.  CNO  —  COWWO  AND  CWTSO*.  EQUIPMENT 

).  tNF  —  INFANTRY  (QUIPWKI 

J.  IN?  dVANtlT  equipment 

«.  «u. 

4.  ttc 

• 

— »  m 

**♦ 

L  J 

N _ 4 

6 

.2-6 

* •  vVv,.‘. j>, . 1 


• Vv  v  v  .* 
V  -.T-.  '  -  CV  -  .  •  <  •  ■  -  v- .• . 


Word  usage  should  correspond  consistently  to  th^  user ' s/operator ’ s 
operational  language.  Avoid  jargon  which  is  not  the  technical 
jargon  of  the  user/operator.  But  retain  jargon  which  is  common  to 
and  is  universally  understood  by  a  group  of  users/operators  (AMMO 
for  AMMUNITION,  for  example). 

Explicitly  define  technical  terms,  terms  that  could  take  on  more 
than  one  meaning,  or  terms  that  are  used  more  specifically  than 
in  their  usual  meaning  in  the  connotation  in  which  they  are  used. 
Use  the  term  only  in  the  predefined  connotation.  For  example, 
the  term  SCREEN  should  not  be  used  to  mean  “display  frame"  in 
one  usage  and  "menu  selection  alternative”  in  another. 

Flexible  usace  of  basic  versions  of  terms  may  be  allowed  for 
experienced  users/operators:  "Y"  for  YES,  “N“  for  NO,  for  example. 
However,  casual  and  inexperienced  users/operators  should  not  even 
be  advised  of  the  availability  of  such  options. 
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6.3  Abbreviations  and  Codes 


6.3.1  DEFINITION 

Abbreviations  and  codes  are  the  user's/operator's  shorthand  for  communi¬ 
cating  with  and  through  the  system.  Abbreviations  are  derived  from  full 
words,  i.e.,  they  are  formed  using  selected  letters/characters  of  words — 
for  example,  "equip1'  for  equipment.  There  exist  conventional  abbreviations 
which  are  widely  accepted  in  general  usage  as  well  as  in  the  military  argot 
(e.g. ,  CPT  for  Captain,  Arty  for  artillery).  Even  with  widely  accepted 
standard  abbreviations,  variation  in  the  use  of  upper  and  lower  case  letters 
and  in  punctuation  is  frequent  and  widespread,  creating  potential  stumbling 
blocks  for  users /operators . 

Codes  are  arbitrary  symbolic  representations  of  things  or  their  names. 

They  can  be  made  up  of  alpha,  numeric,  and  symbolic  symnol  sets,  or  any 
combination  thereof.  Examples  of  alpha,  numeric,  and  grammatical  symbol 
codes  are:  "AN/PSG-2, “  che  equipment  code  for  the  TACFIRE  Digital  Message 
Device;  "750612,"  an  octally  presented  fault  code  for  TACFIRE  indicating 
that  the  key  generator  was  not  ready  to  encrypt  a  message  for  transmission; 
and  "SYS; INIT, "  a  code  label  for  the  TACFIRE  System  Initialization  Message 
format.  Codes  can  be  formed  as  acronyms — a  word  formed  from  the  first 
letters  of  a  series  of  words  or  from  some  first  letter  sets.  For  example, 
the  TACFIRE  Digital  Message  Device  is  more  frequently  known  as  the  "DMD; 11 
"COBOL"  stands  for  common  Business  Oriented  Language;  "BASIC"  stands  for 
Beginner's  All-purpose  Symbolic  Instruction  Code.  Both  of  these  two  latter 
acr  'yms,  and  probably  "CP.T"  (for  Cathode  Ray  Tube),  are  better  known  than 
their  full  language  titles. 

Abbreviations,  codes,  and  acronyms  can  all  be  mnemonics,  i.e.,  designed 
in  such  a  way  as  to  resemble  the  full  word(s)  for  which  they  stand,  thereby 
assisting  the  user's/operator's  memory  function.  It  is  sometimes  difficult  to 
distinguish  between  abbreviations  and  codes;  efforts  to  do  so,  however, 
seem  far  less  important  than  the  consistency  and  appropriateness  of  their  design. 
Table  6.3-1  provides  some  examples  of  abbreviations  and  codes  and  the  use 
of  mnemonics — demonstrating  some  similarities  and  differences  in  derivation 
and  construction.  The  table  ^.s  intended  to  demonstrate  the  need  for  applica¬ 
tion  of  code  design  guidelines  (as,  for  example,  those  presented  in  subsection 
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6.3.5)  rather  than  to  attempt  to  reach  a  distinction  between  abbreviations, 
acronyms,  and  codes. 


Table  6.3-1.  Sample  Abbreviations,  Codes,  and  Mnemonics 


Full  Word  or  Phrase 

Identifier  Label 

Label  Classification 

Equipment 

i 

EQUIP  1 

Abbreviation 

Equipment 

EQMT 

Mnemonic  abbrevia¬ 
tion  or  code 

TACFIRE  Digital 

Message  Device 

AN/PSG-2 

Equipment  code 

Digital  Message 

Device 

HMD 

Acronym 

Division  (mathe¬ 
matics) 

DVN 

Mnemonic  abbrevia¬ 
tion  or  code 

Division  (military) 

DIV 

Abbreviation 

Artillery  Division 

DIVaRTY 

Code 

Forward  Edge  of  Battle 

FEBA 

Acronym 

Forward  Edge  of  Battle 

FRLT 

Code 

Front  Line  Trace 

FRLT 

Acronym 
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Table  6.3-2.  Relationship  of  TACFIRE  Message  Labels 
(Codes)  to  Their  Pull  Language  Names 


MESSAGE  TYPE 


Messaqe  Label 

Category 

Purpose 

Label 

Classification 

SYS; INIT 

System 

Initialize  the  System 
Message 

Abbreviation/Abbre¬ 

viation 

AFU;  DIR 

Ammunition  and 

Fire  Unit 

Message  Directory 

Acronym/Abbreviat  ion 

SPRT;  AIRCOR 

Support 

Air  Corridor  Message 

Mnemonic  Abbreviation/ 
Acronym 

FMiFOCMD 

Tactical  and  Tech¬ 
nical  Fire 

Control 

Forward  Observor 
Command  Message 

Code  *  Mnemonic 
Abbreviation 

NNFPiRESFU 

Non-Nuclear  Fire 
Planning 

Reserve  Fire 

Unit  Message 

Acronym/Abbreviation  + 
Acronym 

MET; COMD 

Meteorological 

user  Commands 

Message 

Abbreviation/Mnemonic 

Abbreviation 

ATI ; CDR 

Artillery  Target 
Intelligence 

Coordinate  Report 
Message 

Acronym/Abbreviat ion  ♦ 
Acronym 

SURV; RE2 

Survey 

Two  Point  Resection 
Data  Message 

Abbreviation/Code 

FSE: NDC1NU 

Fire  Support 

Element 

Nuclear  Burst 

Sighting  Message 

Acronym/Acronym  + 

Code 

Shape  and  color  are  two  additional  dimensions  used  for  symbolic  coding. 
These  two  dimensions  can  be  combined  to  provide  a  very  wide  range  of  code 
elements.  Typical  examples  of  use  of  color  and  symbolic  codes  are  in  quan¬ 
titative  graphics — charts  and  graphs  which  present  contrasting  measures  for 
a  set  of  variables,  e.g.,  the  number  of  tanks  assigned  per  division  across 
a  set  of  calendar  years.  (See  also  Section  2.2,  Graphics  Displays.) 
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6.3.2  APPLICATIONS  OF  ABBREVIATIONS  AND  CODES 

Areas  of  application  for  abbreviations  and  codes  include: 

a.  Cuing  users/operators  as  to  "next  step"  operation  by  specific 
instructions . 

b.  Assisting  users/operators  in  initializing  and  operating  the 
system. 

c.  Requesting  the  next  step  in  an  operation  from  the  user/operator 

d.  Displaying  system  output. 

e.  Presenting  a  message  or  graphics  format  into  which  the  user/ 
operator  must  enter  data. 

f.  Providing  header  information  to  identify  a  nonformatted 
message  or  report. 

g.  Providing  labels  and/or  notations  on  graphics  presentations. 

h.  Providing  error  indications — warning  and  instructional  content. 

i.  Reducing  the  number  of  key  strokes  required  for  system  control 
and  data  entry. 

j.  Reducing  the  amount  of  storage  dedicated  to  system  control. 

k.  Conforming  to  conventions,  standards,  and  doctrine. 

l.  Reducing  the  intrasystem  and  intersystem  communication  burden. 

ra.  Reducing  the  amount  and/or  densivy  of  information  presented  on 
a  given  display  or  page. 
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6.3.3  BENEFITS 


Use  of  abbreviations  and  codes  results  in  the  followings 

a.  More  efficient  utilization  of  system  storage  a..d  processing 
capabilities . 

b.  Increased  intrasystem  and  intersystem  communication. 

c.  Through  reduction  in  presentation  and  product  density, 
increased  user/operator  effectiveness  and  data  handling 
capacity . 
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6.3.4  METHODS 

Methods  to  enhance  the  use  of  abbreviations  and  codes  include: 

a.  Selection  of  standard  terminal  keyboards  which  provide  the 
standard  alpha  and  numeric  symbols  and  the  more  usual  gram¬ 
matical  symbols  from  which  a  great  proportion  of  abbreviations 
and  codes  are  usually  constructed. 

b.  Coordination  of  abbreviation/code  development  and  terminal  key¬ 
board  selection  to  facilitate  abbreviation  and  code  design 

and  usage. 

c.  Incorporation  of  conventional/standard  codes,  especially  those 
called  out  by  doctrine. 

d.  Use  of  off-the-shelf  keyboards  which  permit  incorporation  of 
additional  grammatical  symbols,  special  symbols,  and  graphic 
symbols  to  expand  the  code  element  set. 

e.  Incorporation  of  keyboards  providing  special  symbols  and  termi¬ 
nals  which  allow  generation  of  graphics,  especially  color 
graphics,  to  greatly  expand  the  symbology  coding  capability. 

f.  Use  of  software  to  expand  the  symbolic  symbol  set. 
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6.3.5  RECOMMENDATIONS  FOR  ABBREVIATIONS  AND  CODES 

Although  abbreviations  are  frequently  used  as  codes,  their  methods  of 
construction  and  often  their  usage  are  very  different  from  that  of  codes. 
Therefore,  in  providing  recommendations  for  construction  and  application  of 
abbreviations  and  codes,  the  following  attend  first  to  abbreviations  and 
then  to  codes. 

6.3. 5. I  Recommendations  for  Abbreviations 

a.  Use  abbreviations  instead  of  full  terms  to: 

1.  Reduce  the  amount  of  display  area  required  or  reduce  the 
density  of  the  display  area. 

2.  Reduce  the  amount  of  storage  area  required  per  item  of 
information,  thereby  effecting  increased  system  storage 
capacity . 

3.  Reduce  input,  processing,  and  output  times. 

4.  Reduce  input  and  output  error. 

b.  Define  a  standard  set  of  abbreviations  and  use  them  consistently. 
Good  abbreviations  are  quickly,  easily,  and  unequivocally: 

1.  Associated  with  the  terms  they  represent. 

2.  Discriminated  from  other  abbreviations  within  the  par¬ 
ticular  system  context. 

c.  Incorporation  of  standard  and  well  accepted  abbreviations  is  a 
primary  consideration  in  their  use.  Such  terminology  becomes, 
in  this  instance,  military  argot  and  as  such  communicates  per¬ 
haps  even  more  effectively  than  the  full  language  for  which  it 
stands.  These  terms  are  derived  through  a  variety  of  methods 
for  developing  abbreviations  and,  because  they  are  so  widely 
accepted,  do  not  require  attention  to  or  consistency  in  their 
formulation  rules.  The  following  examples  demonstrate  formu¬ 
lation  of  standard  and  well  accepted  abbreviations  by  different 
rules. 

Abbreviation  Full  Language  Term  Formulation  Rule 

AMMO  Ammunition  Slang  for  ammunition  and 

now  a  fully  accepted  term. 

MAXALT  Maximum  altitude  First  3  letters  of  each 

word. 


6.3-7 


Abbreviation 

Full  Language  Term 

Formulation  Rule 

MAXRNG 

Maximum  range 

First  3  letters;  dele¬ 
tion  of  vowels. 

USARF.UR 

United  States  Army, 

Acronym  using:  first 

Europe 

letters,  first  2  letters, 
first  3  letters. 

d.  Use  the  following  strategies  for  construction  of  abbreviations: 

1.  Simple  truncation.  Drop  off  letters  from  the  right  end 
of  the  word  until  the  desired  abbreviated  length  is 
achieved . 

2.  Truncation  -  Second  letter  out.  Drop  out  the  second 
letter  from  the  left  end  of  the  word,  then  apply  simple 
truncation  until  the  desired  abbreviated  length  is 
achieved. 

3.  Contraction  -  Vowels  out.  Retain  the  first  letter  on 
the  left  end  of  the  word  (vowel  or  consonant) ,  remove 
vowels  and  the  letters  H,  W,  and  Y  until  the  desired 
abbreviated  length  is  achieved.  Supplement  with  simple 
truncation  as  necessary. 

4.  Contraction  -  Frequent  letters  out.  Retain  the  first 
letter  on  the  left  end  of  the  word  and  delete  letters 
from  right  to  left  on  the  basis  of  elimination  of  highest 
frequency  of  occurrence  until  the  desired  abbreviated 
length  is  achieved. 

e.  Preferences  of  military  user  personnel  for  the  above  and  for 

abbreviations  presented  in  the  Data  Element  Dictionary  (DED) 

are  shown  in  Table  6.3-3. 

Table  6.3-3.  Use  and  Preferences  for  Abbreviation  Types 


1  •  Most  preferred/ 
beat 

S  •  Leeat  preferred/ 
vocat 

POWWIATION  TYPE 

CDOC-«U>T«D  ACTIVITY 

Preference 

Only 

Decoding  (Writ¬ 
ing  the  original 
ter»  free  the 
abbreviation) 

Encoding 
(Generation  of 
abbreviation) 

DtO  -  D*t4  ElMWftt 
Dictionary 

5 

S 

2 

iii«ple  Truncation 

7 

l 

l 

Truncation  -  2nd  letter 
out 

4 

4 

Contraction  *  Vowel*  out 

1 

J 

1 

Contraction  -  frequent 
lettera  out 

) 

2 

4 
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f.  Do  not  abbreviate  unless  the  abbreviation  is  significantly 
shorter  or  more  meaningful  than  the  full  term.  Lenth  of  term 

is  an  important  factor  in  developing  abbreviations.  A  good  rule 
is  to  let  the  length  of  the  abbreviation  depend  upon  the  term 
being  abbreviated.  Use  the  following  lengths  as  guidance: 

Number  of  Letters  Number  of  Letters 
in  Original  Term  in  Abbreviation 

5  3 

6-7  4 

8  or  more  5 

g.  On  the  whole,  if  display  and  presentation  space  can  afford 
it,  longer  abbreviations,  especially  if  they  resemble  the 
full  term,  will  consnunicate  better  and  will  be  less  likely 
to  be  confused  than  shorter  abbreviations.  Avoid  abbrevia¬ 
tions  the  user  is  not  likely  to  understand  or  remember  just 
to  make  more  room  for  data  on  the  display. 

h.  Taking  the  construction  strategies  and  the  recommended  length 
into  consideration,  the  sample  abbreviations  shown  in  Table 
6. 3-4  are  derived. 

i.  The  methods  for  structuring/selecting  abbreviations  can  be 
applied  in  the  following  hierarchical  sequence: 

1.  Incorporation  of  conventional,  known,  and  well  accepted 
abbreviations,  especially  in  light  of  user/operator 
experience. 

2.  Simple  truncation  in  accordance  with  tho  structure  and 
length  defined  above. 

3.  The  truncation  -  vowels  out  method  and  length  as  defined 
above. 

j.  It  is  not  necessary  and  is  inappropriate  to  form  ail  abbrevia¬ 
tions  using  only  a  single  formulation  method.  Good  judgment 
will  promote  tho  dovolopeont  of  appropriate  and  well  accepted 
abbreviations. 

k.  Loarnability  of  abbreviations  contributes  to  reduced  user/ 
operator  error  and  increased  system  efficiency.  Factors  which 
contribute  to  loarnability  of  abbreviations  include: 

1.  Utilization  of  standard  and  familiar  abbreviations. 

2.  Construction  in  conformance  with  user/operator  preference. 

3.  To  an  appropriate  extent,  consistency  in  the  method (s) 
applied  In  tho  design  of  abbreviations. 
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Term 

Standard 
Artads  DED 

Single 

Truncation 

Truncation 

2nd  Letter  Out 

Contract ion 
Vowels  Out 

AMMUNITION 

AMMO 

AMMUN 

AMUNI 

AMMNT 

ARTILLERY 

ARTY 

ART1X' 

- 

ATILL 

ARTLL 

AUTHORIZED 

AUTH 

AUTHO 

ATOOR 

ATRZD 

BATTALION 

BN 

BATTA 

BTTAL 

BTTLN 

BRIGADE 

BDE 

BRIG 

BIGA 

BRGD 

“DISTRIBUTEES" 

DISTR 

DISTR 

DSTRI 

DSTRB 

EQUIPMENT 

EQUIP 

EQUIP 

EUIPM 

EQPMN 

HEADQUARTERS 

HQ 

HEADQ 

HADQU 

HDQRT 

LOCATION 

LOC 

IOCAT 

LCATI 

LCTON 

ORDNANCE 

ORD 

ORDNA 

ODNAN 

ORDNN 

PLATOON 

PLT 

PLAT 

PATO 

PLTN 

REINFORCEMENT 

RNr 

REINF 

RINFO 

RNFRC 

RESTRICTION 

RESTR 

RESTR 

RSTRI 

RSTRC 

ROUNDS 

RDS 

ROUN 

RUND 

FtNDS 

SECURITY 

SCTY 

SECUR 

SCURI 

SCRTY 

1 

SQUADRON 

SQD 

SQUAD 

SUADR 

SQDRN 

SURVEILLANCE 

SURVL 

SURVE 

SRVEI 

SRVLL 

TARGET 

TGT 

TARG 

TRGE 

TRGT 

UNKNOWN 

UNK 

UNKN 

. 

UKNO 

.  .  _  .  ... 

UNKN 
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4.  Attention  to  the  uniqueness/discriminability  of  abbrevia¬ 
tions  . 

1.  Except  for  abbreviations  which  have  become  so  common  as  to  be 
recognized  as  full  words  (e.g.,  AMMO  for  AMMUNITION),  avoid 
using  them  in  output.  If  it  is  necessary  to  use  less  familiar 
abbreviations  in  output,  they  should  be  distinct  and  unambiguous 
within  the  use  context. 


m.  Allowable  usage  of  abbreviations  should  not  exclude  usage  of 
the  full  words.  For  example,  experienced  users  probably  prefer 
an  abbreviation  rather  than  the  full  word  in  making  command 
entries?  inexperienced  users  probably  prefer  to  have  the  option 
of  using  the  abbreviation  or  the  full  command  term. 

n.  If  the  use  of  abbreviations  is  permitted  in  the  construction 
of  full  text  reports ,  provide  *  'ftware  to  expand  these  abbre¬ 
viated  terms  to  full  language  when  the  report  is  presented 

as  output. 

o.  Use  all  upper  case  letters  for  abbreviations. 

p.  Avoid  punctuation  within  abbreviations  to  the  extent  possible. 
In  particular,  do  not  use  periods  if  they  can  be  avoided. 


Use 

USAF 

4  in  front 
dimension 


Do  Not  Use 

U.S.A.F. 

4-in.  front 
dimension 


USAREUK 


U.S.  Ar .  Eur. 
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6. 3. 5. 2  Recommendations  for  Codes 

a.  Control  needy  to  be  exercised  over  the  design  of  codes.  The 
followinq  conditions  contribute  to  this  control: 

1-  Codes  are  designed  by  code  design  experts. 

2.  Maintain  consistency  in  the  code  design  strategies 
applied.  Centralized  control  of  code  design  enhances 
consistency. 

3.  Design  codes  in  accordance  with  user  capabilities  and 
limitations. 

4.  Pay  attention  to  tradeoffs  between  design  for  optimum 
human  code  usage  and  maximum  machine  handling  capabili¬ 
ties. 

5.  A  clear  understanding  cf  the  rules  applied  in  code 
construction  is  essential. 

b.  Good  code  design  takes  three  aspects  into  consideration: 

1.  Human  considerations  -  uhe  acceptability  of  the  code  and 
the  relationship  of  code  design  to  user/operator  code 
usage  for: 

(a)  Perceiving  codes. 

(b)  Interpreting  codes. 

(c)  Responding  to  codes. 

(d)  beaming  codes. 

(e)  Entering  codes. 

(f)  Discriminating  codes  from  each  other. 

2.  Machine  considerations  -  the  relationship  of  the  code 
design  to  processing  capabilities  and  capacities  such 

fa)  Storage  and  handling  capacities. 

U»  Error  tolerance. 

{c>  Enror  correction  strategies. 

(d(  Interc  wigeabiiity  of  information. 


5-  design  conSiderat iin.S  -  the  relationships  of  code 

design  strategies  and  options  to  human  and  machine 
crpabilities  and  capacities,  including: 


(a)  Available  symbols  and  symbol  sets 


(b)  Existing  codes  and  abbreviations  which  have  become 
standard  in  a  given  context. 

(c)  The  amount  of  information  to  be  coded. 

(d)  The  expandability/rigidity  of  the  code  set(s). 

Design  codes  for  the  anticipated  user  s/operators  with  the  least  experience 
and/or  the  lowest  skill  level. 

For  codes  which  will  be  used  extensively,  use  only  symbols  which 
are  very  familiar  to  the  antic_p“'  .v  users/operators. 

Take  user/operator  preferences  into  account  in  designing  codes.  Some 
known  user/operator  preferences  include: 

1.  Alpha  characters  rather  than  numeric. 

2.  Numeric  characters  for  data  which  can  be  so  represented. 

Example:  for  the  date  "24  January  1982,“  use  “01/24/82" 
rather  than  “JAN/24/82"  or  JA/24/82." 

3.  Codes  which  are  all  alpha  or  all  numeric,  rather  tha., 
mixed  alphanumeric  codes. 

4.  In  general,  use  shorter  rather  than  longer  codes.  (But, 
see  also  items  h,  j,  1,  and  m.) 

Break  longer  codes  into  “chunks.'*  For  example:  “046-342-7932“ 
for  a  telephone  number  rather  titan  “0463427932.“  or,  “HAS  ALT" 
rather  than  "HAXALT“  for  "Maximum  altitude." 

Make  as  strong  a  relationship  between  the  eode  and  its  root 
meaning  as  possible.  Dropping  vowels  and  forming  mnemonics 
help  greatly  in  this  instance.  For  example:  "TNK  IHUVF*  for 
“Tank  Brigade."  Hnemonie  codes  vhieh  conform  to  population 
stereotypes  are  excellent.  These  codes  are  quickly  recalled 
and  recognised  and  are  unambiguous,  dome  examples  are: 


Code 

Full  Term 

A3WQ 

Ammunition 

equip 

Equipment 

1*2 

headquarters 

ter 

Target 

TfiSC 

Tank 

USiK 

Unknown 
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h.  If  meaningless  arbitrary  codes  must  be  used — either  all  alpha 
or  all  numeric — make  the  codes  no  longer  than  four  or  five 
characters. 

i.  If  meaningless  arbitrary  codes  must  be  composed  of  both  alpha 
and  numeric  symbols,  group  alpha  characters  together  and 
numeric  symbols  together.  For  example:  use  "WC4 , "  not  "W4C . " 

j .  When  abbreviated  codes  are  used  to  shorten  data  entry ,  make  the 
codes  as  distinctive  as  possible.  For  example:  "REM"  versus 
"BAL”  is  good  and  "BAL"  versus  "BAS"  is  bad.  On  the  other  hand, 
however,  in  forming  codes  for  a  series  of  word  combinations, 
maintain  code  consistency  to  the  extent  possible.  For  example: 


Code 

Full 

Terw. 

AMOK 

Ammunition 

expended 

AMOH 

Ammunition 

on  hand 

AMOR 

Ammunition 

received 

k.  In  dealing  with  codes  for  both  entering  and  interpreting  infor¬ 
mation,  users/operators  will  usually  deal  with  codes  from  a 
variety  of  code  sets.  (For  example,  codes  for  equipment, 
locations,  quantities,  date/time,  etc.)  Therefore,  employ  code 
desion  strategies  which  are: 

1.  Consistent  enough  to  provide  uniformity  of  design. 

2.  Different  to  the  extent  required  to  provide  discrimin- 
ability  of  codes. 

l.  Single  letter  or  single  numeric  codes  are  not  usually  good 
for  making  discriminations  since  their  meaning  and  even  their 
identification  can  be  very  ambiguous.  One  exception  to  this, 
however,  is  tne  use  of  a  singlo  numeric  as  a  menu  selection 
indicator.  For  example: 
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m.  Longer  codes  can  contribute  to  increasing  code  usage  error  for 
the  simple  reason  of  expanded  memorization  requirements.  On 

the  other  hand,  longer  codes  contribute  to  code  discriminability. 
Therefore,  tradeoffs  between  preventing  errors  (with  shorter 
code)  and  creating  errors  (with  longer  codes)  need  to  be  consid¬ 
ered.  One  rule  to  apply  is  to  keep  the  symbol  set(s)  as  small 
as  possible  in  consideration  of  the  code  set(s)  required,  since 
the  larger  the  "vocabulary"  base  from  which  codes  are  constructed, 
the  more  difficult  the  code  learning/association  process. 

n.  Single  vocabulary  (symbol  set)  code  systems  reduce  user/opera¬ 
tor  error.  However,  as  information  sets  become  larger  and  more 
code  sets  are  required,  additional  code  vocabularies  (symbol  sets) 
are  required  to  express  meanings  explicitly  and  unequivocally. 

If  special  symbol  sets  are  required,  use  individual  symbols  which 
are  easibly  distinguished  from  one  another. 

o.  Color  can  be  used  for  special  coding  or  to  expand  pictorial 
and  even  alphanumeric  coding.  When  color  is  employed  as  part 
of  coding,  certain  precautions  are  necessary: 

1.  Associate  a  single  color  with  only  a  single  meaning  on 
a  screen. 

2.  Make  color  associations  as  consistent  ar.d  conventional 
as  possible.  Some  standard  meanings  already  attached 
to  specific  colors  which  are  appropriate  even  when  used 
on  a  green  screen  include: 


Color 

Meaning 

Red 

Alarms  or  data  requiring 

immediate  attention 

Yellow 

Warnings  or  data  that  may 

require  attention 

White 

Highlighting  detail 

3.  A  maximum  of  8  or  9  highly  saturated  colors  can  be  easily 
discriminated. 

4.  Provide  a  "key"  to  color  codes  online. 

p.  Color  added  to  shape  codes  as  a  redundancy  increases  recogni¬ 
tion  accuracy  and  reduces  recognition  time. 

q.  Colors  are  affected  by  lighting  conditions.  Low  lighting 
reduces  the  discriminability  of  colors.  Increasing  bright¬ 
ness  contrast  increases  color  discriminability. 
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6.4  Full  Language 


6.4.1  DEFINITION 

Full  language  in  this  context  is  the  use  of  conventional  written  or  printed 
text  for  interaction  with  and  through  the  system.  Standard  rules  and  opera¬ 
tions  of  grammar  and  syntax  apply;  presentation  conventions  relevant  to  a  body 
of  scientific  or  technical  information  are  also  employed  when  appropriate. 


6.4.3  BENEFITS 


Use  of  full  language  permits  the  followings 

a.  Versatility  in  the  input  and  presentation  of  information. 

b.  A  natural  flow  of  information  which  facilitates  rapid  and 
unencumbered  system  operation. 

c.  A  system  output  which  can  be  formatted  to  any  set  of  external 
standards. 


6.4.4  METHODS 


Methods  which  can  be  used  for  provision  of  full  language  capability 
include: 

a.  Use  of  standard  terminal  keyboards  which  provide  the  standard 
alpha  and  numeric  symbols  and  the  appropriate  grammatical  sym¬ 
bols. 

b.  Provision  of  keybaords  which  incorporate  a  set  of  symbols  appro¬ 
priate  to  a  given  area  of  science  or  technology,  as  these  are 
required. 

c.  Use  of  software  which  processes  full  text. 


6.4.5  RECOMMENDATIONS  FOR  FULL  LANGUAGE 


a.  The  primary  rule  of  full  text  presentation  is  to  make  the  lan¬ 
guage  meaningful  to  the  user. 

b.  Full  language  requires  presentation  of  information  in  directly 
usable  form.  Do  not  require  the  user  to  make  any  translation 
(such  as  transposing,  converting,  interpreting,  interpolating, 
etc.)  into  any  other  terms  or  units. 

c.  Make  the  information  presented  in  full  lnaguage  text  as 
"straight"  as  possible,  i.e.,  deviod  of  humor,  ridicule,  or 
punishment.  Avoid  "anthromorphism, 11  vernacular  or  dialectic 
language,  and  slang. 

d.  Output  speed  is  associated  with  text  utilization.  If  the  ter¬ 
minal's  output  spaed  is  less  than  normal  reading  speed  (about 
250  words  per  minute) ,  more  compact  messages  can  be  used.  If 
the  terminal  speed  is  greater  than  250  words  per  minute,  full 
language  is  required. 

e.  In  presenting  textual  material,  minimize  hyphenation  of  words. 

Text  is  more  readable  if  hyphenations  are  avoided.  The  chance 
of  incorrect  hyphenation  is  also  avoided. 

f.  Do  not  use  contractions  in  textual  presentations.  For  example, 
do  not  use  "don't,"  use  "do  not." 

g.  When  codes  and  abbreviations  have  been  used  in  entering  infor¬ 
mation  which  becomes  incorporated  into  full  language  reports 
or  other  full  language  presentations,  automatically  convert 
the  abbreviations  and  codes  into  full  language.  If  such 
conversion  is  not  automatic  (i.e.,  handled  by  the  software), 
m'-ke  such  conversion  manually  for  inclusion  into  formal/ 
standard  reports. 

h.  Use  standard  punctuation  in  full  language  presentations. 

i.  In  full  language  presentations,  use  terminology  which  is 
consistent,  defined,  and  documented.  For  terms  that  are 
technical,  that  can  take  more  than  one  meaning,  or  that  are 
used  more  specifically  than  their  usual  meaning  warrants, 
provide  explicit  definitions  in  the  connotation  used. 

j.  Assure  that  words  assume  meanings  or  connotations  appropriate  to 

the  users /operators  rather  than  to  the  programmer  or  system  designer. 
Some  ways  to  avoid  the  user/programmer  confusion  about  given 
words  include; 

1.  Use  only  words  the  user /operator  is  likely  to  know. 

2.  Use  words  that  are  not  likely  to  be  interpreted  in  many 
different  ways  or  in  ways  other  than  the  user/operator  would 
know. 
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3.  Use  words  to  mean  only  a  single  thing  and  not  different 
things  in  different  contexts  or  in  different  stages  of  a 
dialog. 

4.  Use  simple  language  to  the  extent  possible.  Avoid  complex 
constructions . 

In  presenting  text  on  a  small  screen,  do  not  exceed  50-55 
characters  per  line.  On  larger  screens,  break  text  into  2 
columns  of  30  -  35  characters  per  line.  Separate  columns  by 
at  least  5  spaces  if  the  text  is  not  right  justified  and  by 
3  or  4  spaces  if  it  is  right  justified. 


6.4-6 


6.5  Glossaries 


6.5.1  DEFINITION 

A  glossary  provides  a  list  and  definitions  of  selected  symbols  and  termi¬ 
nology  associated  with  a  restricted  subject  matter  area.  Glossaries  can  be  of 
any  size;  they  can  be  presented  on-line  through  the  system  or  off-line  through 
a  variety  of  mediums. 
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6.5.2  APPLICATIONS  OP  GLOSSARIES 

Glossaries  can  be  used  to: 

a.  Identify  a  set  of  legal  entries. 

b.  Identify  the  correct  entry  given  a  set  of  conditions. 

c.  Demonstrate  correct  structure  and  syntax  of  an  entry. 

d.  Provide  definition  for  abbreviated  or  coded  output. 

a.  Assure  the  use  of  standard  or  proper  symbology/terminology  in: 

1.  System  control. 

2.  Data  entry. 

3.  Message  composition. 

4.  Report  generation. 

i.  Assist  correct  interpretation  of  displayed  information. 
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6.5.3  BENEFITS 

Availability  of  a  glossary  or  a  set  of  glossaries  will,  result  in  the 
following  benefits: 

a.  Efficient  system  operation. 

b.  Unambiguous  intrasystem  communication. 

c.  Reduced  user/operator  time  and  error,  as  well  as  reduced  frus¬ 
tration. 

On-line  presentation  of  glossaries  will  enhance  all  of  the  above  benefits  above 
off-line  presentation. 
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6.5.4  METHODS 


Methods  for  assuring  glossary  availability  and  use  include: 

a.  Presentation  of  standard  terms  (legal  entries)  in  system  HELP 
files. 

b.  Provision  of  glossary  elements  in  menus  and  prompts. 

c.  Default  incorporation  of  standard  terms  (legal  entries)  in 
report  and  message  header  and  fields. 

d.  Presentation  of  standard  terms  and  other  glossary  items  in 
off-line  documentation  such  as  special  job  aids  and  user  man¬ 
uals. 


6.5.5  RECOMMENDATIONS  FOR  GLOSSARIES 


a.  Compile  a  dictionary/glossary  of  all  codes,  abbreviations, 
symbols,  and  standard  terms  which  are  required  by  the  user/ 
operator.  Provide  glossaries  both  in  hard  copy  documentation 
and  on-line  through  software. 

b.  A  primary  rule  for  the  presentation  of  glossaries—whether  on¬ 
line  or  off-line — is  that  they  are  formulated  so  as  to  be 
accessible  to  the  user/operator.  Such  a  requirement  may  make 
more  than  one  presentation  of  glossaries  and/or  other  reference 
sources  necessary.  Some  examples  of  different  types  of  presen¬ 
tation  include: 

1.  Alphabetical  listing  of  glossary  terms  and  their  defini¬ 
tions. 

2.  Alphabetical  lists  of  potential  glossary  terms  which  the 
user/operator  might  consider  and  through  which  are  indi¬ 
cated  : 

(a)  The  correct  term  (i.e.,  the  term  to  be  used). 

(b)  Definitions  of  similar  terms  so  that  distinctions 
are  drawn  between  terms. 

3.  Hierarchical  presentation  of  sets  of  information,  as 
appropriate . 

c.  Glossaries  demonstrate  correct  structure  and  syntax  of  data 
entries  as  well  as  the  correct  data  entry. 

d.  Provide  glossaries  for  the  system' 3  operational  commands  as 
shown  in  Table  6.5-1,  Alphabetical  Glossary  of  Commands; 

Table  6.5-2,  Glossary  of  Commands  organized  by  Operation; 
and  Table  6.5-3,  Glossary  of  Commands  Organized  by  Potential 
Commands. 
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Table  6.5-1.  Cont'd 


RECOMMENDED 

COMMAND 

OPERATION 

POTENTIAL 

COMMANDS 

APPEND 

Append  new  information  to  an 
existing  file  or  set  of 
information . 

ADD 

ADJOIN 

AFFIX 

APPEND 

ATTACH 

INCREASE 

INSERT 

ALPHABETIZE 

Arrange  a  set  of  data  in  an 
alphabetical  sequence. 

ALPHABETIZE 

SEQUENCE 

SERIALIZE 

ARRAY 

Make  rectangular  arrangement 
of  data  into  rows  and  columns. 

ARRANGE 

ARRAY 

BLOCK 

ASSIGN 

Set  file  space  aside  for 
spec:  al  purpose. 

ASSIGN 

DEDICATE 

AUDIT 

Call  up  numeric  data  for 
'Examination . 

AUDIT 

AUTHENTICATE 

EXAMINE 

VALIDATE 

VERIFY 

AUTHENTICATE 

Establish  data  or  set  of  infor¬ 
mation  as  genuine. 

AUTHENTICATE 

VALIDATE 

VERIFY 

AVERAGE 

Calculate  the  aritlimetic  mean 
of  a  set  of  numeric  data. 

AVERAGE 

CALCULATE 

MEAN 

BRANCH 

Form  an  expansion  to  a  file  or 
set  of  information  separate 
from  the  main  part. 

ATTACH 

BPANgH 

EXPAND 

FORK 
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RECOMMENDED 

COMMAND 

OPERATION 

POTENTIAL 

COMMANDS 

BREAK 

Stop  print.  Discontinue 
print  of  file  or  set  of 
information. 

ABORT 

BREAK 

DISCONTINUE 

STOP 

BUILD 

Define  an  output  format. 

BUILD 

FORMAT 

CALENDAR 

Print  schedule /calendar . 

CALENDAR 

SCHEDULE 

CALL 

Call  up  a  function  or  pro¬ 
cessing  routine. 

CALL 

FETCH 

FILE 

FILE  = 

FIND 

GET 

NAME 

CEASE 

End  (stop)  all  operations. 

ABORT 

CEASE 

END 

HALT 

QUIT 

STOP 

CHRONICLE 

Arrange  a  set  of  data  in  a 
historical  sequence. 

CALENDAR 
CHRONICLE  . 
SEQUENCE 

CODE 

Transform  full  language  to 
coded  information  state. 

CHANGE 

CODE 

TRANSFORM 

COLOR 

Add  color  to  a  displayed  out¬ 
put. 

COLOR 

INTENSIFY 

RECOLOR 
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Table  6.5- 

RECOMMENDED 
COMMAND _ 

COMBINE 

COMMENT 

CONDENSE 

CONNECT 

CONTINUE 

CONVERT 

COPY 


COUNT 


1.  Cont'd 


OPERATION 


POTENTIAL 

COMMANDS 


Integrate  one  file  or  set  of 
information  with  another. 


ASSIMILATE 

COMBINE 

INTEGRATE 

JOIN 

MERGE 


Add  remarks  to  a  file  or  set  of 
information . 


ADD 

COMMENT 

REMARK 


Condense  a  file  or  set  of 
information . 


ABRIDGE 

CONDENSE 

EXTRACT 


Activate  a  peripheral  unit. 


ACTIVATE 

ACTUATE 

CONNECT 

EXECUTE 


Continue  with  current  action.  CONTINUE 


Change  data  into  another  measure-  CHANGE 
ment  form .  CONVERT 

TRANSFORM 


Copy  a  file  or  set  of  infer-  CLONE 

nation .  COPY 

DISK 

DUP 

DUPLICATE 
RECORD  D 
RECORD  T 
REPEAT 
REWRITE 
TAPE 


Determine  the  numbor  of  things 
in  a  series. 


COUNT 

ENUMERATE 

NUMBER 
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RECOMMENDED  POTENTIAL 

COMMAND  OPERATION  _ COMMANDS 


DATE  Indicate  date  only  of  opera-  CALENDAR 

tion  or  event.  DATE 

DATE/TIME 

DATE/TIME  Indicate  date  and  time  of  opera-  CALENDAR 

tion .  DATE 

DATE/TIME 

DECODE  Transform  coded  information  to  CHANGE 

full  text.  DECODE 

TRANSFORM 

DECREASE  Decrease  a  counter.  DECREASE 

SUBTRACT 


DEFER  Postpone  processing  indefinitely.  DEFER 

DELAY 

HALT 

HOLD 

PAUSE 

POSTPONE 


DELAY  Delay  for  stated  amount  of  time.  DEFER 

DELAY 

HALT 

HOLD 

PAUSE 

POSTPONE 


DELETE  Delete  an  existing  file  or  set  ABORT 

of  information.  CLEAR 

DELETE 

DESTROY 

RILL 

LOGOFF 

CHIT 

PURGE 

REMOVE 

UNSAVE 

ZAP 
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6.5.5 


RECOMMENDED 

COMMAND 


OPERATION 


POTENTIAL 

COMMANDS 


DELIMIT 


Set  boundaries  around  a 
stated  value. 


BOUND 

DELIMIT 

LIMIT 


DIRECTORY 


Display  index  of  all  avail¬ 
able  files  of  information . 


DIRECTORY 

DISPLAY 

FII£S 

INDEX 

LIST 

SHOW 


DISCLAIM 


Deny  the  validity/authenticity 
of  data  or  set  of  information. 


DENY 

DISAUTHENTICATE 

DISCLAIM 


DISCONNECT 


Sever  the  connection  between  a  DISCONNECT 
peripheral  unit  and  the  CPU.  UNDO 


Store  a  file  or  set  of  infor¬ 
mation  on  disk. 


COPY 

DISK 

DOUT 

FILE 

PILEOUT 

HOLD 

HOLD  D 

KEEP 

RECORD 

RECORD  D 

RETAIN 

SAVE 

STORE 

WRITE 

WRITE  TO  DISK 
W  2  DK 


DISPLAY 


Display  a  report  or  partial 
report  on  the  screen. 


DISPLAY 

SNOW 


DIVIDE 


Perform  the  mathematical  opera-  DIVIDE 

tion  of  division.  SEPARATE 
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RECOMMENDED 

COMMAND 


OPERATION 


POTENTIAL 

COMMANDS 


EDIT 

Edit  a  file  or  set  of  infor¬ 
mation. 

CORRECT 

EDIT 

UPDATE 

ENTER 

Admit  information  into  the 
system. 

ADMIT 

ENTER 

EXCHANGE 

Exchange  one  piece  of  infor¬ 
mation  for  another. 

EXCHANGE 

MOVE 

SUBSTITUTE 

TRANSFER 

TRANSPOSE 

EXECUTE 

Call  up  and  use  a  specific 
procedure/program . 

EXECUTE 

RUN 

START 

EXTRACT 

Extract  portion  from  file  or 
set  of  information. 

ABRIDGE 

CONDENSE 

EXTRACT 

FILTER 

Screen  out  specified  types  of 
information  from  a  file  or 
set  of  information. 

FILTER 

SCREEN 

SEPARATE 

SORT 

FIN) 

Pind  a  designated  portion  of  a 
file  {i.e. ,  data  within  a 
file) . 

FIND 

GET 

SEARCH 

SEEK 

FORMAT 

Define  an  input  or  output 
format. 

build 

FORM 

FORMAT 

INPUT 

OUTPUT 

REPORT 

WRITE 
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RECOMMENDED 

COMMAND 


OPERATION 


POTENTIAL 

COMMANDS 


GET 

Indicate  a  file  or  set  of 
information  to  work  with. 

CONNECT 

DEFINE 

FETCH 

FILE 

FILE  * 

FIND 

GET 

LOAD 

RECALL 

REQUEST 

SELECT 

USE 

HELP 

Lend  assistance. 

HELP 

INCREASE 

Increment  a  counter. 

ADD 

ADVANCE 

INCREASE 

INCREMENT 

INDEX 

Display  index  of  all  files. 

DIRECTORY 

DISPLAY 

FILES 

INDEX 

INQUIRY 

Request  for  indication  of  types 
of  function  needed. 

CALL 

INQUIRY 

INSERT 

Insert  new  information  in  file 
or  sat  of  information. 

ADD 

INSERT 

INTENSIFY 

Intensify  the  existing  color  of  a 
displayed  output. 

CHANGE 

COLOR 

INTENSIFY 

RECOLOR 

JOIN 

Attach  one  file  to  the  end  of 
another  file. 

APPEND 

ATTACH 

JOIN 
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RECOMMENDED 

COMMAND 


LOGOFF 


LOGON 


MERGE 


MODIFY 


MOVE 


MULTIPLY 


1.  Cant'd 


POTENTIAL 

OPERATION _ COMMANDS 


Leave  the  system.  ABORT 

BYE 

DONE 

END 

EXIT 

LOGOFF 

OFF 

QUIT 

SIGNOFF 

STOP 

Enter  the  system.  BEGIN 

ENTER 

ID 

IDENT 

LOGON 

SIGNON 

USER 


Merge  data  in  a  file  or  set 
of  information. 


ADJOIN 

ADMIT 

CONCATENATE 

CONNECT 

INSERT 

JOIN 

rfBKGp 


Modify  a  file  or  set  of  infor-  ADAPT 

mation  to  a  certain  specif i-  ADJUST 

cation.  ALTER 

CHANGE 

MODIFY 


Move  information  within  a  file 
or  set  of  information. 


EXCHANGE 

MOVE 

TRANSFER 

TRANSPOSE 


Perform  the  mathematical  opera¬ 
tion  of  multiplication. 


EXPAND 

MULTIPLY 
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Cont'd 

RECOMMENDED 

COMMAND 

OPERATION 

POTENTIAL 

COMMANDS 

NEWFILE 

Create  a  new  file  or  set  of  infor¬ 
mation. 

CREATE 

FILE 

FILE  = 

FILEOUT 

NEW 

NEWFILE 

NUMBER 

Assign  sequential  numbers  to 
things  in  a  series 

COUNT 

ENUMERATE 

NUMBER 

OMIT 

Exclude  a  piece  of  information 
from  a  report. 

DELETE 

DESTROY 

OMIT 

REMOVE 

OVERPRINT 

Enter  data  within  an  input  or 
ovitput  format  so  as  to  erase 
and  replace  existing  infor¬ 
mation. 

OVERPRINT 

OVERWRITE 

PRINT 

WRITE 

PAGE  AHEAD 

Page  forward. 

CARRIAGE  RETURN 

FORWARD 

NEXT 

PAGE 

PAGE  AHEAD 


PAGE  BACK  Pago  backward.  BACK 

BACKWARD 

PAGE 

PAGE  BACK 
PAGE  BACKWARD 

PREVIOUS 


PAUSE  Stop  t.o«potarily .  HALT 

PAUSE 

POSTPONE 


PRINT  Print  a  hard  copy.  COPY 

LIST 

l£>  B 

OUTPUT 

PRINT 

WRITE 
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RECOMMENDED 

COMMAND  OPERATION 


l 


POTENTIAL 

COMMANDS 


PROTECT 


Protect  a  file  or  set  of  infor¬ 
mation. 


PRESERVE 

PROTECT 

READ 

SAVE 


RECOLOR 

Change  the  color  of  a  displayed 
output . 

CHANGE 

COLOR 

RECOLOR 

REPLY 

Request  a  reply  frcea  the  CPU 
or  another  terminal. 

ANSWER 

REPLY 

RESPOND 

REMOVE 

Delete  a  piece  of  information 
from  a  file  or  set  of  infor¬ 
mation. 

DELETE 

DESTROY 

OMIT 

REMOVE 

SAVE 

Store  a  film  or  set  of  infor¬ 
mation 

RECORD 

SAVE 

STORE 

SCREEN  Screen  out  specified  types  of  FILTER 

information  to  be  assimilated  SCREEN 

in  a  file  or  set  of  infor-  SEPARATE 

nation .  SORT 

SEARCH  Find  designated  file.  FIND 


GET 

SEARCH 

S.DEK 


SELECT  Select  and  activate  a  computer-  ACTIVATE 

controlled  device.  ACTUATE 

AFFIX 

ATTACH 

CONNECT 

EXECUTE 

GO 

SELECT 


WWTE 


- 
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'/i 


RECOMMENDED 

COMMAND 


SEPARATE 


SEQUENCE 


SERIALIZE 


SHOW 


SORT 


STATUS 


SUBTRACT 


OPERATION 

POTENTIAL 

COMMANDS 

0'  1 

Arrange  data  into  two  or  more 

ARRANGE 

files  or  sets  of  information. 

DIVIDE 

•  1 

SEPARATE 

SORT 

- 

,V 

Arranqe  a  set  of  data  in  a 

ARRAY 

causal -results  sequence. 

ARRANGE 

f 

SEQUENCE 

SERIALIZE 

Arrange  a  set  of  data  in  a 

ARRANGE 

V 

.V 

specified  sequential  order. 

ENUMERATE 

8 

NUMBER 

SEQUENCE 

fT 

L 

SERIALIZE 

V 

a 

■  • 

*  « 

Display  the  content  of  a  field. 

DISPLAY 

V  , 

,  » 

,  \ 

*  ' 

LIST 

SHOW 

V 

TERMINAL 

| 

TO  » 

VIEW 

:* 

WRITE 

ft 

W  2  TO 

'% 

Sort  data  in  a  file  or  set  of 

ARRANGE 

r 

* 

information. 

ARRAY 

k 

ASSORT 

ORDER 

SEQUENCE 

ft'* 

SORT 

f 

Get  system  status. 

GET 

h 

STATUS 

SYSTAT 

•L 

„■  ♦ ! 

Perform  the  mathematical  opora- 

DELETE 

s 

i 

tion  of  subtraction. 

REDUCE 

£ 

SUBTRACT 

& 

*  %  ■ 

■  *\ 

V', 
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RECOMMENDED 

COMMAND 


TRANSCRIBE 


TRANSFER 


TRANSPOSE 


VALIDATE 


VERIFY 


WRITE 


OPERATION _ 

Calculate  the  sum  of  a  set  of 
numbers . 


Notify  user/operator  at  another 
terminal  of  a  condition  or 
event . 


Copy  a  file  or  set  of  infor¬ 
mation  from  one  storage  type 
to  another  (e .  g . ,  tape  'co 
disk,  disk  to  tape). 

Move  information  from  one  file 
to  another. 


Exchange  the  order  (sequence) 
of  two  pieces  of  information 
within  a  file. 


Prove  as  true  by  presenting 
other /detailed  information. 


Substantiate  truth  or  authen¬ 
ticity  by  expertise. 


Wait  for  input. 


Write  a  file  or  set  of  infor¬ 
mation  on  tape. 


POTENTIAL 

COMMANDS 

ACCRETE 

ACCRUE 

ACCUMULATE 

ADD 

SUM 

ADVISE 

APPRISE 

NOTIFY 

TELL 

SAVE 

TRANSCRIBE 

TRANSFER 

WRITE 

EXCHANGE 

MOVE 

TRANSCRIBE 

TRANSFER 

TRANSPOSE 

EXCHANGE 

MOVE 

TRANSFER 

TRANSPOSE 

AUTHENTICATE 

CONFIRM 

VALIDATE 

VERIFY 

AUTHENTICATE 

CONFIRM 

VALIDATE 

VERIFY 

DELAY 

HOLD 

WAIT 

COPY 
HOLD  T 
RECORD  T 
SAVE 
TAPE 
TAPEOUT 
TOUT 
WRITE 

WRITE  TO  TAPE 
W  2  TP 
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Table  6.5-2.  Glossary  of  Commands  Organized  by  Operation 


OPERATION 


POTENTIAL 

COMMANDS 


RECOMMENDED 

COMMAND 


Discontinue  current  operation. 


Accumulate  a  running  total  of 
incoming  numeric  data. 


Acknowledge  a  message  from  the 
CPU  or  another  terminal. 


Activate  a  computer-controlled 
device  • 


Accumulate  a  presented  set  of 
numeric  values ,  summing  to  a 
total • 


Make  changes  to  existing  file  or 
set  of  information- 


Accept  nonstandard  input , 


ABORT 

ABRIDGE 

CEASE 

END 

HALT 

PAUSE 

QUIT 

STOP 


ABORT 


ACCRETE 

ACCRUE 

ACCUMULATE 

ADD 

SUM 


ACCRUE 


ACKNOWLEDGE 

ANSWER 

MESSAGE 

REPLY 


ACKNOWLEDGE 


ACTIVATE 

EXECUTE 

GO 

START 


ACTIVATE 


ACCRETE 

ACCRUE 

ACCUMULATE 

ADD 

SUM 


ADD 


ADAPT 

ADJUST 

ALTER 

CHANGE 

MODIFY 


ADJUST 


ACCEPT 

ADMIT 

ENTER 


ADMIT 
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Cont'd 


OPERATION 


POTENTIAL 

COMMANDS 


Append  new  information  to  an  ADD 

existing  file  or  set  of  infor-  ADJOIN 

mation.  AFFIX 

APPEND 

ATTACH 

INCREASE 

INSERT 


Arrange  a  set  of  data  in  an 
alphabetical  sequence* 


ALPHABETIZE 

SEQUENCE 

SERIALIZE 


Make  rectangular  arrangement  of 
data  into  rows  and  columns* 


ARRANGE 

ARRAY 

BLOCK 


Set  file  space  aside  for 
special  purpose* 


ASSIGN 

DEDICATE 


Call  up  numeric  data  for 
examination. 


AUDIT 

AUTHENTICATE 

EXAMINE 

VALIDATE 

VERIFY 


Establish  data  or  set  of  infor¬ 
mation  as  genuine. 


AUTHENTICATE 

VALIDATE 

VERIFY 


Calculate  the  arithmetic  mean  of 
a  set  of  numeric  data. 


AVERAGE 

CALCULATE 

MEAN 


Form  an  expansion  to  a  file  or  ATTACH 

set  of  information  separate  from  BRANCH 
the  main  part.  EXPAND 

FORK 


RECOMMENDED 

COMMAND 


APPEND 


ALPHABETIZE 


ARRAY 


ASSIGN 


AUDIT 


AUTHENTICATE 


AVERAGE 


BRANCH 
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OPERATION 


POTENTIAL 

COMMANDS 


RECOMMENDED 

COMMAND 


Stop  print.  Discontinue 
print  of  file  or  set  of 
information . 


ABORT 

BREAK 

DISCONTINUE 

STOP 


BREAK 


Define  an  output  format. 


BUILD 

FORMAT 


BUILD 


Print  schedule/calendar . 


CALENDAR 

SCHEDULE 


CALENDAR 


Call  up  a  function  or  pro¬ 
cessing  routine. 


CALL 

FETCH 

FILE 

FILE  = 

FIND 

GET 

NAME 


End  (stop)  all  operations. 


ABORT 

CEASE 

END 

HALT 

QUIT 

STOP 


CEASE 


Arrange  a  set  of  data  in  a 
historical  sequence. 


Transform  full  language  to 
coded  information  state. 


CALENDAR 

CHRONICLE 

SEQUENCE 


CHANGE 

CODE 

TRANSFORM 


CHRONICLE 


Add  color  to  a  displayed  out¬ 
put. 


COLOR 

INTENSIFY 

RECOLOR 


COLOR 
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OPERATION 

POTENTIAI# 

COMMANDS 

RECOMMENDED 

COMMAND 

Integrate  one  file  or  set  of 
information  with  another. 

ASSIMILATE 

COMBINE 

INTEGRATE 

JOIN 

MERGE 

COMBINE 

Add  remarks  to  a  file  or  set  of 
information . 

ADD 

COMMENT 

REMARK 

COMMENT 

Condense  a  file  or  set  of 
information. 

ABRIDGE 

CONDENSE 

EXTRACT 

CONDENSE 

Activate  a  peripheral  unit. 

ACTIVATE 

ACTUATE 

CONNECT 

EXECUTE 

CONNECT 

Continue  with  current  action. 

CONTINUE 

CONTINUE 

Change  data  into  another  measure¬ 
ment  form. 

CHANGE 

CONVERT 

TRANSFORM 

convert 

Copy  a  file  or  set  of  infor¬ 
mation. 

CLONE 

COPY 

DISK 

DUP 

DUPLICATE 

RECORD  D 

RECORD  T 

REPEAT 

REWRITE 

TAPE 

COPY 

Determine  the  number  of  things 
in  a  series. 


COUNT 

ENUMERATE 

NUMBER 


COUNT 


{ 

i 
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OPERATION 


POTENTIAL 

COMMANDS 


RECOMMENDED 

COMMAND 


Indicate  date  only  of  opera¬ 
tion  or  event. 


CALENDAR 

DATE 

DATE/TIME 


Indicate  date  and  time  of  opera¬ 
tion  or  event. 


CALENDAR 

DATE 

DATE/TIME 


DATE/TIME 


Transform  coded  information  to 
full  text. 


CHANGE 

DECODE 

TRANSFORM 


DECODE 


Decrease  a  counter. 


DECREASE 

SUBTRACT 


DECREASE 


Postpone  processing  indefinitely. 


DEFER 

DELAY 

HALT 

HOLD 

PAUSE 

POSTPONE 


DEFER 


Delay  for  stated  amount  of  time. 


DEFER 

DELAY 

HALT 

HOLD 

PAUSE 

POSTPONE 


DELAY 


Delete  an  existing  file  or  sot 
of  information. 


ABORT 

CLEAR 

DELETE 

DESTROY 

KILL 

LOGOFF 

OMIT 

PURGE 

REMOVE 

UNSAVE 

ZAP 


DELETE 


6.5-23 


Table  6.5-2.  Cont'd 


OPERATION 


POTENTIAL 

COMMANDS 


Set  boundaries  around  a 
stated  value. 


BOUND 

DELIMIT 

LIMIT 


Display  Index  of  all  avail¬ 
able  files  of  information. 


DIRECTOR* 

DISPLAY 

FILES 

INDEX 

LIST 

SHOW 


Deny  the  validity/authenticity 
of  data  or  set  of  Information. 


DENY 

DISAUTHENTICATE 

DISCLAIM 


Sever  the  connection  between  a 
peripheral  unit  and  the  CPU. 


DISCONNECT 

UNDO 


Store  a  file  or 
tion  on  disk. 


set  of  informa- 


COPY 

DISK 

DOUT 

FILE 

FILEOUT 

HOLD 

HOLD  D 

KEEP 

RECORD 

RECORD  D 

RETAIN 

SAVE 

STORE 

WRITE 

WRITE  TO  DISK 
W  2  DK 


Display  a  report  or  partial 
report  on  the  screen. 


DISPLAY 

SHOW 


Perform  the  mathematical  opera¬ 
tion  of  division. 


DIVIDE 

SEPARATE 


RECOMMENDED 

COMMAND 


DELIMIT 


DIRECTORY 


DISCLAIM 


DISCONNECT 


DISK 


DISPLAY 


DIVIDE 
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OPERATION 

POTENTIAL 

COMMANDS 

RECOMMENDED 

COMMAND 

Edit  a  file  or  set  of  infor¬ 

CORRECT 

EDIT 

mation. 

EDIT 

UPDATE 

Admit  information  into  the 

ADMIT 

ENTER 

system. 

ENTER 

Exchange  one  piece  of  infor¬ 

EXCHANGE 

EXCHANGE 

mation  for  another. 

MOVE 

SUBSTITUTE 

TRANSFER 

TRANSPOSE 

Call  up  and  use  a  spacific 

EXECUTE 

EXECUTE 

procedure/program . 

RUN 

START 

Extract  portion  from  file  or  set 

ABRIDGE 

EXTRACT 

of  information. 

CONDENSE 

EXTRACT 

Screen  out  specified  types  of 

FILTER 

FILTER 

information  from  a  file  or 

SCREEN 

set  of  information. 

SEPARATE 

SORT 

Find  a  designated  portion  of  a 

FIND 

PIND 

file  (i.e.,  data  within  a 

GET 

file). 

SEARCH 

SEEK 

Define  an  input  or  output 

BUILD 

FORMAT 

format. 

FORM 

FORMAT 

INPUT 

OUTPUT 

REPORT 

WRITE 
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OPERATION 

POTENTIAL 

COMMANDS 

RECOMMENDED 

COMMAND 

Indicate  a  file  or  set  of 
information  to  work  with. 

CONNECT 

DEFINE 

FETCH 

FILE 

FILE  o 

FIND 

GET 

LOAD 

RECALL 

REQUEST 

SELECT 

USE 

GET 

lend  assistance. 

HELP 

HELP 

Increment  a  counter. 

ADD 

ADVANCE 

INCREASE 

INCREMENT 

INCREASE 

Display  index  of  all  files. 

DIRECTORY 

DISPLAY 

FILES 

INDEX 

INDEX 

Request  for  indication  of  types 
of  function  needed. 

CALL 

INQUIRY 

INQUIRY 

Insert  new  information  in  file 
or  sot  of  information. 

ADD 

INSERT 

INSERT 

Intensify  the  existing  color  of  a 
displayed  output. 

CHANGE 

COLOR 

INTENSIFY 

RECOLOR 

INTENSIFY 

Attach  one  file  to  the  end  of 
another  file. 

APPEND 

ATTACH 

JOIN 

JOIN 

Table  6.5-2.  Cont'd 

POTENTIAL 

RECOMMENDED 

OPERATION 

COMMANDS 

COMMAND 

Leave  the  system. 

ABORT 

BYE 

DONE 

END 

EXIT 

LOGOFF 

OFF 

QUIT 

SIGNOFF 

STOP 

LOGOFF 

Enter  the  system. 

BEGIN 

ENTER 

ID 

IDENT 

LOGON 

SIGNON 

USER 

LOGON 

Merge  data  in  a  file  or  set 

ADJOIN 

MERGE 

of  information. 

ADMIT 

CONCATENATE 

CONNECT 

INSERT 

JOIN 

MERGE 

Modify  a  file  or  set  of  informa¬ 

ADAPT 

MODIFY 

tion  to  a  certain  specification. 

ADJUST 

ALTER 

CHANGE 

MODIFY 

Move  information  within  a  file 

EXCHANGE 

MOVE 

or  sot  of  information. 

MOVE 

TRANSFER 

TRANSPOSE 

Perform  the  mathematical  opera¬ 

EXPAND 

MULTIPLY 

tion  of  multiplication. 

MULTIPLY 
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POTENTIAL  RECOMMENDED 

OPERATION _ COMMANDS  COMMAND 


Create  a  new  file  or  set  of  infor¬ 
mation. 

CREATE 

FILE 

FILE  = 

FILEOUT 

NEW 

NEWFILE 

NEWFILE 

Assign  sequential  numbers  to 
things  in  a  series. 

COUNT 

ENUMERATE 

NUMBER 

NUMBER 

Exclude  a  piece  of  information 
from  a  report. 

DEIETE 

DESTROY 

OMIT 

REMOVE 

OMIT 

Enter  data  within  an  input  or 
output  format  so  as  to  erase 
and  replace  existing  informa¬ 
tion. 

OVERPRINT 

OVERWRITE 

PRINT 

WRITE 

OVERPRINT 

Page  forward. 

CARRIAGE  RETURN 
FORWARD 

NEXT 

PAGE 

PAGE  AHEAD 

PAGE  AHEAD 

Page  backward. 

BACK 

BACKWARD 

PAGE 

PAGE  BACK 

PAGE  BACKWARD 
PREVIOUS 

PAGE  BACK 

Stop  temporarily. 

HALT 

PAUSE 

POSTPONE 

PAUSE 
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POTENTIAL 

RECOMMENDED 

OPERATION 

COMMANDS 

COMMAND 

Print  a  hard  copy. 

copy 

LIST 

LP  = 

OUTPUT 

PRINT 

WRITE 

PRINT 

Protect  a  file  or  set  of  informa¬ 

PRESERVE 

PROTECT 

tion. 

PROTECT 

READ 

SAVE 

Change  the  color  of  a  displayed 

CHANGE 

RECOLOP. 

output . 

COLOR 

RECOLOR 

Request  a  reply  from  the  CPU 

ANSWER 

REPLY 

or  another  terminal. 

REPLY 

RESPOND 

Delete  a  piece  of  information 

DELETE 

REMOVE 

from  a  file  or  set  of  informa¬ 

DESTROY 

tion. 

OMIT 

REMOVE 

Store  a  file  or  sot  of  informa¬ 

RECORD 

SAVE 

tion. 

SAVE 

STORE 

Screen  out  specified  types  of 

FILTER 

SCREEN 

information  to  be  assimilated 

SCREEN 

in  a  file  or  set  of  informa¬ 

SEPARATE 

tion. 

SORT 

Find  designated  file. 

FIND 

GET 

SEARCH 

SEEK 

SEARCH 
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OPERATION 


POTENTIAL 

COMMANDS 


RECOMMENDED 

COMMAND 


Select  and  activate  a  computer- 
controlled  device. 


ACTIVATE 

ACTUATE 

AFFIX 

ATTACH 

CONNECT 

EXECUTE 

GO 

SELECT 


SELECT 


Arrange  data  into  two  or  more 
files  or  sets  of  information. 


ARRANGE 

DIVIDE 

SEPARATE 

SORT 


SEPARATE 


Arrange  a  set  of  data  in  a 
causal-results  sequence. 


ARRANGE 

ARRAY 

SEQUENCE 

SERIALIZE 


SEQUENCE 


Arrange  a  set  of  data  in  a 
specified  sequential  order. 


ARRANGE 

ENUMERATE 

NUMBER 

SEQUENCE 

SERIALIZE 


SERIALIZE 


Display  the  content  of  a  field. 


DISPLAY 

LIST 

SHOW 

TERMINAL 
TO  - 
VIEW 
WRITE 
W  2  TO 


SHOW 


Sort  data  in  a  file  or  ( at  of 
information. 


ARRANGE 

ARRAY 

ASSORT 

ORDER 

SEQUENCE 

SORT 


SORT 
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OPERATION 


POTENTIAL 

COMMANDS 


RECOMMENDED 

COMMAND 


Get  system  status. 


Perform  the  mathematical  opera¬ 
tion  of  subtraction . 


Calculate  the  sum  of  a  set  of 
numbers. 


Notify  user/operator  at  another 
terminal  of  a  condition  or 
event. 


Copy  a  file  or  set  of  infor¬ 
mation  from  one  storage  type 
to  another  (e.g.,  tape  to 
disk,  disk  to  tape). 


Hove  information  from  one  file 
to  another. 


Exchange  the  order  (sequence) 
of  two  pieces  of  information 
within  a  file. 


GET 

STATUS 

SYSTAT 


DELETE 

REDUCE 

SUBTRACT 


ACCRETE 

ACCRUE 

ACCUMULATE 

ADD 

SUM 


ADVISE 

APPRISE 

NOTIFY 

TELL 


SAVE 

TRANSCRIBE 

TRANSFER 

WRITE 


EXCHANGE 

HOVE 

TRANSCRIBE 

TRANSFER 

TRANSPOSE 


EXCHANGE 

HOVE 

TRANSFER 

transpose 


STATUS 


SUBTRACT 


SUM 


TELL 


TRANSCRIBE 


TRANSFER 


TRANSPOSE 
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Cont'd 


OPERATION 


POTENTIAL 

COMMANDS 


Prove  as  true  by  presenting 
other/detailed  information. 


AUTHENTICATE 

CONFIRM 

VALIDATE 

VERIFY 


Substantiate  truth  or  authen¬ 
ticity  by  expertise. 


AUTHENTICATE 

CONFIRM 

VALIDATE 

VERIFY 


Wait  for  input. 


DELAY 

HOLD 

WAIT 


Write  a  file  or  set  of  informa¬ 
tion  on  tape. 


COPY 
HOLD  T 
RECORD  T 
SAVE 
TAPE 
TAPEOUT 
TOUT 
WRITE 

WRITE  TO  TAPE 
W  2  TP 


RECOMMENDED 

COMMAND 


VALIDATE 


VERIFY 


WAIT 


WRITE 


Table  6-5-3.  Glossary  of  Commands  Organized  by  Potential  Commands 


POTENTIAL 

COMMAND 

OPERATION 

RECOMMENDED 

COMMAND 

ABORT 

Discontinue  current  operation. 

ABORT 

Stop  print.  Discontinue  print 
of  file  or  set  of  information. 

BREAK 

End  (stop)  all  operations. 

CEASE 

Delete  an  existing  file  or  set 
of  information. 

DELETE 

Leave  the  system. 

LOGOFF 

ABRIDGE 

Discontinue  current  operation. 

ABORT 

Condense  a  file  or  set  of  infor¬ 
mation  . 

CONDENSE 

Extract  portion  from  file  or  set 
of  information. 

EXTRACT 

ACCEPT 

Accept  nonstanda^u  input. 

ADMIT 

ACCRETE 

Accumulate  a  running  total  of 
incoming  numeric  data. 

ACCRUE 

Accumulate  a  presented  set  of 

numeric  values,  summing  to  a  total. 

ADD 

Calculate  the  sum  of  a  set  of 
numbers. 

SUM 

ACCRUE 

Accumulate  a  running  total  of 
incoming  numeric  data. 

ACCRUE 

Accumulate  a  presented  set  of 

numeric  values,  summing  to  a  total. 

ADD 

Calculate  the  sum  of  a  set  of 
numbers. 

SUM 

Table  6.5-3,  Cont'd 


POTENTIAL 

COMMAND 


OPERATION 


RECOMMENDED 

COMMAND 


ACCUMULATE 

Accumulate  a  running  total  of 
incoming  numeric  data. 

ACCRUE 

Accumulate  a  presented  set  of 
numeric  values,  summing  to  a 
total . 

ADD 

Calculate  the  sum  of  a  set  of 
numbers. 

SUM 

ACKNOWLEDGE 


Acknowledge  a  message  from  the 
CPU  or  another  terminal. 


ACKNOWLEDGE 


ACTIVATE 

Activate  a  computer-controlled 
device . 

ACTIVATE 

Activate  a  peripheral  unit. 

CONNECT 

Select  and  activate  a  computer- 
controlled  device. 

SELECT 

ACTUATE 

Activate  a  peripheral  unit. 

CONNECT 

Select  and  activate  a  computer- 
controlled  device. 

SELECT 

ADAPT 


Make  changes  to  existing  file  or 
set  of  information. 


ADJUST 


Modify  a  file  or  set  of  infor¬ 
mation  to  a  certain  specifi¬ 
cation  . 


MODIFY 


6.5-34 


Table  6.5-3.  Cont'd 


POTENTIAL  RECOMMENDED 


COMMAND 

OPERATION 

COMMAND 

ADD 

Accumulate  a  running  total  of 
incoming  numeric  data. 

ACCRUE 

Accumulate  a  presented  set  of 
numeric  values,  summing  to  a 
total. 

ADD 

Append  new  information  to  an 
existing  file  or  set  of  infor¬ 
mation  . 

APPEND 

Add  remarks  bo  a  file  or  set  of 
information. 

COMMENT 

Increment  a  counter. 

INCREASE 

Insert  new  information  in  file 
or  set  of  information. 

INSERT 

Calculate  the  sum  of  a  set  of 
numbers. 

SUM 

ADJOIN 

Append  new  information  to  an 
existing  file  or  set  of  infor¬ 
mation  . 

APPEND 

Merge  data  in  a  file  or  set  of 
information. 

MERGE 

ADJUST 

Make  changes  to  existing  file  or 
set  of  information. 

ADJUST 

Modify  a  file  or  set  of  infor¬ 
mation  to  a  certain  specifi¬ 
cation. 

MODIFY 

ADMIT 

Accept  nonstandard  input. 

ADMIT 

Admit  information  into  the 
system. 

ENTER 

Merge  data  in  a  file  or  set 

MERGE 

of  information. 
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POTENTIAL  RECOMMENDED 

COMMAND  OPERATION  _  _ COMMAND 


ADVANCE 


Increment  a  counter. 


INCREASE 


ADVISE  Notify  user/operator  at  another  TELL 

terminal  of  a  condition  or 
event. 


AFFIX  Append  new  information  to  an  APPEND 

existing  file  or  set  of  infor¬ 
mation. 

Select  and  activate  a  computer-  SELECT 

controlled  device. 


ALPHABETIZE  Arrange  a  set  of  data  in  an  ALPHABETIZE 

alphabetical  sequence. 


ALTER  Make  changes  to  existing  file  or  ADJUST 

set  of  information. 

Modify  a  file  or  set  of  infor-  MODIFY 

mation  to  a  certain  specifi¬ 
cation  . 


ANSWER  Acknowledge  a  message  from  the  ACKNOWLEDGE 

CPU  or  another  terminal. 

Request  a  reply  from  the  CPU  REPLY 

or  another  terminal. 


APPEND  Append  new  information  to  an  APPEND 

existing  file  or  set  of  infor¬ 
mation. 

Attach  one  file  to  the  end  of  JOIN 

another  file. 
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POTENTIAL 

COMMAND 

OPERATION 

RECOMMENDED 

COMMAND 

APPRISE 

Notify  user/operator  at  another 
terminal  of  a  condition  or 
event . 

TELL 

ARRANGE 

Make  rectangular  arrangement  of 
data  into  rows  and  columns. 

ARRAY 

Arrange  data  into  two  or  more 
files  or  sets  of  information. 

SEPARATE 

Arrange  a  set  of  data  in  a 
causal-results  sequence . 

SEQUENCE 

Arrange  a  set  of  data  in  a 
specified  sequential  order. 

SERIALIZE 

Sort  data  in  a  file  or  set  of 
information. 

SORT 

ARRAY 

Make  rectangular  arrangement  of 
data  into  rows  and  columns. 

ARRAY 

Arrange  a  set  of  data  in  a 
causal-results  sequence. 

SEQUENCE 

Sort  data  in  a  file  or  set  of 
information. 

SORT 

ASSIGN 

Set  file  space  aside  for 
special  purpose. 

ASSIGN 

ASSIMILATE 

Integrate  one  file  or  set  of 
information  with  another. 

COMBINE 
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POTENTIAL 

COMMAND 

OPERATION 

RECOMMENDED 

COMMAND 

ASSORT 

Sort  data  in  a  file  or  set  of 
information. 

SORT 

ATTACH 

Append  new  information  to  an 
existing  file  or  set  of  infor¬ 
mation  . 

APPEND 

Form  an  expansion  to  a  file  or 
set  of  information  separate  from 
the  main  part. 

BRANCH 

Attach  one  file  to  the  end  of 
another  file. 

JOIN 

Select  and  activate  a  computer- 
controlled  device. 

SELECT 

AUDIT 

Call  up  numeric  data  for 
examination. 

AUDIT 

AUTHENTICATE 

Call  up  numeric  data  for 
examination . 

AUDIT 

Establish  data  or  set  of  infor¬ 
mation  as  genuine. 

AUTHENTICATE 

Prove  as  true  by  presenting 
other/detailed  information. 

VALIDATE 

Substantiate  truth  or  authen¬ 
ticity  by  expertise. 

VERIFY 

AVERAGE  ' 

Calculate  the  arithmetic  mean  of 
a  set  of  numeric  data. 

AVERAGE 

BACK  Page  backward.  PAGE  BACK 
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Table  6.5-3. 

Cont 1  d 

POTENTIAL 

COMMAND 

OPERATION 

RECOMMENDED 

COMMAND 

BACKWARD 

Page  backward. 

PAGE  BACK 

BEGIN 

Enter  the  system. 

LOGON 

BLOCK 

Make  rectangular  arrangement  of 
data  into  rows  and  columns. 

ARRAY 

BOUND 

Set  boundaries  around  a 
stated  value. 

DELIMIT 

BRANCH 

Form  an  expansion  to  a  file  or 
set  of  information  separate  from 
the  main  part. 

BRANCH 

BREAK 

Stop  print .  Discontinue 
print  of  file  or  set  of 
information. 

BREAK 

BUILD 

Define  an  output  format. 

BUILD 

BYE 

Leave  the  system. 

LOGOFF 

CALCULATE 

Calculate  the  arithmetic  mean  of 
a  set  of  numeric  data. 

AVERAGE 
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POTENTIAL 

COMMAND 

OPERATION 

RECOMMENDED 

COMMAND 

CALENDAR 

Print  schedule/calendar . 

CALENDAR 

Arrange  a  set  of  data  in  a 
historical  sequence. 

CHRONICLE 

Indicate  date  only  of  opera¬ 
tion  or  event. 

DATE 

Indicate  date  and  time  of  opera¬ 
tion  or  event. 

DATE/TIME 

CALL 

Call  up  a  function  or  pro¬ 
cessing  routine. 

CALL 

Request  for  indication  of  types 
of  function  needed. 

INQUIRY 

CARRIAGE  RETURN 

Page  forward. 

PAGE  AHEAD 

CEASE 

Discontinue  current  operation. 

ABORT 

End  (stop)  all  operations. 

CEASE 
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POTENTIAL 

COMMAND 

OPERATION 

RECOMMENDED 

COMMAND 

COLOR 

.Add  color  to  a  displayed  out¬ 
put. 

COLOR 

Intensify  the  existing  color  of  a 
displayed  output. 

INTENSIFY 

Change  the  color  of  a  displayed 
output . 

RECOLOR 

COMBINE 

Integrate  one  file  or  set  of 
information  with  another. 

COMBINE 

COMMENT 

Add  remarks  to  a  file  or  set  of 
information. 

COMMENT 

CONCATENATE 

Merge  data  in  a  file  or  set 
of  information. 

MERGE 

CONDENSE 

Condense  a  file  or  set  of 
information . 

CONDENSE 

Extract  a  portion  from  a  file  or 
set  of  information. 

EXTRACT 

CONFIRM 

Prove  as  true  by  presenting 
other/detailed  information. 

VALIDATE 

Substantiate  truth  or  authen¬ 
ticity  by  expertise. 

VERIFY 
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Table  6.5-3. 

Cont'd 

POTENTIAL 

COMMAND 

OPERATION 

RECOMMENDED 

COMMAND 

CONNECT 

Activate  a  peripheral  unit. 

CONNECT 

Indicate  a  file  or  set  of 
information  to  work  with. 

GET 

Merge  data  in  a  file  or  set 
of  information. 

MERGE 

Select  and  activate  a  computer- 
controlled  device. 

SELECT 

CONTINUE 

Continue  with  current  action. 

CONTINUE 

CONVERT 

Change  data  into  another  measure¬ 
ment  form. 

CONVERT 

COPX 

Copy  a  file  or  set  of  inform 
mation. 

COPY 

Store  a  file  or  set  of  informa¬ 
tion  on  disk. 

DISK 

Print  hard  copy. 

PRINT 

Write  a  file  or  set  of  infor¬ 
mation  on  tape. 

WRITE 

CORRECT 

Edit  a  file  or  set  of  inf or- 

EDIT 

motion. 
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POTENTIAL 

COMMAND 

OPERATION 

RECOMMENDED 

COMMAND 

CREATE 

Create  a  new  file  or  set  of  infor¬ 
mation. 

NEWFILE 

DATE 

Indicate  date  only  of  opera¬ 
tion  or  event. 

DATE 

Indicate  date  and  time  of  opera¬ 
tion  or  event. 

DATE/TIME 

DATE/TIME 

Indicate  date  only  of  opera¬ 
tion  or  event. 

DATE 

Indicate  date  and  time  of  opera¬ 
tion  or  event. 

DATE/TIME 

DECODE 

Transform  ceded  information  to 
ful!  text. 

DECODE 

DECREASE 

Decrease  a  counter. 

DECREASE 

DEDICATE 

Set  file  space  aside  for 
special  purpose. 

ASSIGN 

DEFER 

Postpone  processing  indefinitely. 

DEFER 

Delay  for  stated  amount  of  time.  BELAY 


c 

W* 

L. 

Table  6.5-3. 

Cont'd 

6.5.5 

l;; 

POTENTIAL 

RECOMMENDED 

f 

*  « 

COMMAND 

OPERATION 

COMMAND 

*> 

DELAY  Postpone  processing  indefinitely.  DEFER 


Delay  for  stated  amount  of  time.  DELAY 

Wait  for  input.  WAIT 


DELETE 

Delete  an  existing  file  or  set 
of  information. 

DELETE 

Exclude  a  piece  of  information 
from  a  report. 

OMIT 

Delete  a  piece  of  information 
from  a  file  or  set  of  infor¬ 
mation. 

REMOVE 

Perform  the  mathematical  opera¬ 
tion  of  subtraction. 

SUBTRACT 

DESTROY 

Delete  an  existing  file  or  set 
of  information. 

DELETE 

Exclude  a  piece  of  information 
from  a  report. 

OMIT 

Delete  a  piece  of  information 
from  a  file  or  set  of  infor¬ 
mation. 

REMOVE 
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POTENTIAL 

COMMAND 

OPERATION 

RECOMMENDED 

COMMAND 

DIRECTORY 

Display  index  of  all  available 
files  of  information. 

DIRECTORY 

Display  index  of  all  files. 

INDEX 

DISAUTHENTICATE 

Deny  the  validity/authenticity 
of  data  or  set  of  information. 

DISCLAIM 

DISCLAIM 

Deny  the  validity /authenticity 
of  data  or  set  of  information. 

DISCLAIM 

DISCONNECT 

Sever  the  connection  between  a 
peripheral  unit  and  the  CPU. 

DISCONNECT 

DISCONTINUE 

Stop  print .  Discontinue 
print  of  file  or  set  of 
information . 

BREAK 

DISK 

Copy  a  file  or  set  of  infor¬ 
mation  . 

COPY 

Store  a  file  or  set  of  infor¬ 
mation  on  disk. 

DISK 

DISPLAY 

Display  index  of  all  available 
files  of  information. 

DIRECTORY 

Display  a  report  or  partial 
report  on  the  screen. 

DISPLAY 

Increment  a  counter. 

INCREASE 

Display  the  content  of  a  field 


SHOW 


Table  6.5-3.  Cont'd 


POTENTIAL 

COMMAND 


OPERATION 


RECOMMENDED 

COMMAND 


DIVIDE 

Perform  the  mathematical  opera¬ 
tion  of  division. 

DIVIDE 

Arrange  data  into  two  or  more 
files  or  sets  of  information. 

SEPARATE 

Leave  the  system. 


LOGOFF 


Store  a  file  or  set  of  infor 
mation  on  disk. 


Copy  a  file  or  set  of  infor¬ 
mation. 


DUPLICATE 

Copy  a  file  or  set  of  infor' 

mation . 

Discontinue  current  operation. 

ABORT 

End  (stop)  all  operations  . 

CEASE 

Leave  the  system. 

LOGOFF 
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j  POTENTIAL 

|  COMMAND 

OPERATION 

RECOMMENDED 

COMMAND 

ENUMERATE 

Determine  the  number  of  things 
in  a  series. 

COUNT 

4. 

J 

Assign  sequential  numbers  to 
things  in  a  series. 

NUMBER 

to 

1 

• 

Arrange  a  set  of  data  in  a 
specified  sequential  order. 

SERIALIZE 

fcVCV-^A 


EXCHANGE 

Exchange  one  piece  of  infor¬ 
mation  for  another. 

EXCHANGE 

Move  information  within  a  file 
or  set  of  information. 

MOVE 

Move  information  from  one  file 
to  another. 

TRANSFER 

Exchange  the  order  (sequence) 
of  two  pieces  of  information 
within  a  file. 

TRANSPOSE 

EXECUTE 

Activate  a  computer-controlled 
device. 

activate 

Activate  a  peripheral  unit. 

CONNECT 

Call  up  and  use  a  specific 
procedure/program . 

EXECUTE 

Select  and  activate  a  computer- 
controlled  device. 

SELECT 

Leave  the  system. 
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Table  6.5-3. 

Cont'd 

POTENTIAL 

COMMAND 

OPERATION 

RECOMMENDED 

COMMAND 

EXPAND 

Form  an  expansion  to  a  file  or 
set  of  information  separate  from 
the  main  part. 

BRANCH 

Perform  the  mathematical  opera¬ 
tion  of  multiplication. 

MULTIPLY 

EXTRACT 

Condense  a  file  or  set  of 
information. 

CONDENSE 

Extract  a  portion  from  a  file  or 
a  set  of  information. 

EXTRACT 

FETCH 

Call  up  a  function  or  pro¬ 
cessing  routine. 

CALL 

Indicate  a  file  or  set  of 
information  to  work  with. 

GET 

FILE 

Call  up  a  function  or  pro¬ 
cessing  routine. 

CALL 

Store  a  file  or  set  of  infor¬ 
mation  on  disk. 

DISK 

Indicate  a  file  or  set  of 
information  to  work  with. 

GET 

Create  a  new  file  or  set  of  infor¬ 
mation. 

NEWFILE 

FILE  » 

Call  up  a  function  or  pro¬ 
cessing  routine. 

CALL 

Indicate  a  file  or  sot  of 
information  to  work  with. 

GET 

Create  a  new  file  or  set  of  infor- 

NEWFILE 
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POTENTIAL  RECOMMENDED 

COMMAND  OPERATION  COMMAND 


FILEOUT 

Store  a  file  or  set  of  infor¬ 
mation  on  disk. 

DISK 

Create  a  new  file  or  set  of  infor¬ 
mation  . 

NEWFILE 

FILES 

Display  index  of  all  avail¬ 
able  files  of  information. 

DIRECTORY 

Display  index  of  all  files. 

INDEX 

FILTER 

Screen  out  specified  types  of 
information  from  a  file  or 
set  of  information. 

FILTER 

Screen  out  specified  types  of 
information  to  be  assimilated 
in  a  file  or  set  of  infor¬ 
mation  . 

SCREEN 

FIND 

Call  up  a  function  or  pro¬ 
cessing  routine. 

CALL 

Find  a  designated  portion  of  a 
file  (i.e.,  data  within  a 
file) . 

FIND 

Indicate  a  file  or  set  of 
information  to  work  with. 

GET 

Find  designated  file. 

SEARCH 

FORK 

Perm  an  expansion  to  a  file  or 
set  of  information  separato  from 
the  main  part. 

BRANCH 

FORM 

Define  an  input  or  output 
format. 

FORMAT 

G.5-S0 

Table 

6 . 5-3 .  Cont 1  d 

POTENTIAL 

COMMAND 

OPERATION 

RECOMMENDED 

COMMAND 

*r 

FORMAT 

Define  an  output  format. 

BUILD 

l  ° 

\ 

Define  an  input  or  output 
format . 

FORMAT 

f*: 

FORWARD 

Page  forward. 

PAGE  AHEAD 

j 

GET 

Call  up  a  function  or  pro¬ 
cessing  routine. 

CALL 

u 

i 

:: 

Find  a  designated  portion  of  a 
file  (i.e.,  data  within  a 
file) . 

FIND 

■ 

Indicate  a  file  or  set  of 
information  to  work  with. 

GET 

:S 

Find  designated  file. 

SEARCH 

Get  system  status. 

STATUS 

GO 

Activate  a  computer-controlled 
device . 

ACTIVATE 

V, 

V, 

:* 

SmJ 

M 

Select  and  activate  a  computer- 
controlled  device. 

SELECT 

,v* 

/%• 

HALT 

Discontinue  current  operation. 

ABORT 

,y 

.v 

End  (stop)  all  operations. 

CEASE 

s 

JT 

. 

Postpone  processing  indefinitely. 

DEFER 

"  * 

v 

c. 

Delay  for  stated  amount  of  time. 

DELAY 

V. 

1 

nAj 

ic 

Stop  temporarily. 

PAUSE 
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V 
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POTENTIAL  RECOMMENDED 

COMMAND _ OPERATION _ COMMAND 

HELP  Lend  assistance.  HELP 

HOLD  Postpone  processing  indefinitely.  DEFER 

Delay  for  stated  amount  of  time.  DELAY 

Store  a  file  or  set  of  infor-  DISK 

mation  on  disk. 

Wait  for  input.  WAIT 

HOLD  D  Store  a  file  or  set  of  infor-  DISK 


mation  on  disk. 


HOLD  T  Write  a  file  or  set  of  infor-  WRITE 

mation  on  tape. 


ID 

Enter  the  system. 

LOGON 

IDENT 

Enter  the  system. 

LOGON 

INCREASE 

Append  new  information  to  an 
existing  file  or  set  of  infor¬ 
mation. 

APPEND 

Increment  a  counter. 

INCREASE 

INCREMENT 

Incremont  a  counter. 

INCREASE 

INDEX 

Display  index  of  all  available 
files  of  information. 

DIRECTORY 

Display  index  of  all  files. 

INDEX 
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Table  6.5-3. 

Cont 1 d 

POTENTIAL 

COMMAND 

OPERATION 

RECOMMENDED 

COMMAND 

INPUT 

Define  an  input  or  output 
format. 

FORMAT 

INQUIRY 

Request  for  indication  of  types 
of  function  needed. 

INQUIRY 

INSERT 

Append  new  information  to  an 
existing  file  or  set  of  infor¬ 
mation  . 

APPEND 

Merge  data  in  a  file  or  set 
of  information. 

MERGE 

Insert  new  information  in  file 
or  set  of  information. 

INSERT 

INTEGRATE 

Integrate  one  file  or  set  of 
information  with  another. 

COMBINE 

INTENSIFY 

Add  color  to  a  displayed  out¬ 
put. 

COLOR 

Intensify  the  existing  color  of  a 
displayed  output. 

INTENSIFY 

JOIN 

Integrate  one  file  or  set  of 
information  with  another. 

COMBINE 

Merge  data  in  a  file  or  set 
of  information. 

MERGE 

Attach  one  file  to  tne  end  of 
another  file. 

JOIN 

KEEP 

Store  a  file  or  set  of  infor¬ 
mation  on  disk. 

DISK 
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Table  6.5-3.  Cont 1 d 


POTENTIAL 

COMMAND 


OPERATION 


RECOMMENDED 

COMMAND 


MESSAGE 


Acknowledge  a  message  from  the 
CPU  or  another  terminal. 


ACKNOWLEDGE 


MODIFY 

Make  changes  to  existing  file  or 
"set  of  information. 

ADJUST 

Modify  a  file  or  set  of  infor¬ 
mation  to  a  certain  specifi¬ 
cation  . 

MODIFY 

Exchange  one  piece  of  infor¬ 
mation  for  another. 

EXCHANGE 

Move  information  within  a  file 
or  set  of  information. 

MOVE 

Move  information  from  one  file 
to  another. 

TRANSFER 

Exchange  the  order  (sequence) 
of  two  pieces  of  information 
within  a  file. 

TRANSPOSE 

MULTIPLY 


Perform  the  mathematical  opera¬ 
tion  of  multiplication. 


MULTIPLY 


Call  up  a  function  or  pro 
cessing  routine. 


Create  a  new  file  or  set  of  infor¬ 
mation  . 


NEWFILE 
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Table  6.5-3.  Cont'd 


POTENTIAL 

COMMAND 

OPERATION 

RECOMMENDED 

COMMAND 

NEXT 

Page  forward. 

PAGE  AHEAD 

NOTIFY 

Notify  user/operator  at  another 
terminal  of  a  condition  or 
event. 

TELL 

NUMBER 

Determine  the  number  of  things 
in  a  series. 

COUNT 

Assign  sequential  numbers  to 
things  in  a  series. 

NUMBER 

Arrange  a  set  of  data  in  a 
specified  sequential  order. 

SERIALIZE 

OFF 

Leave  the  system. 

LOGOFF 

OMIT 

Delete  an  existing  file  or  set 
of  information. 

DELETE 

Exclude  a  piece  of  information 
from  a  report 

OMIT 

Delete  a  piece  of  information 
from  a  file  or  set  of  infor¬ 
mation. 

REMOVE 

ORDER 

Sort  data  in  a  file  or  set  of 
information. 

SORT 

OVERPRINT 

Enter  data  within  an  input  or 
output  format  so  as  to  erase 
and  replace  existing  infor¬ 
mation. 

OVERPRINT 
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S.5-5f 


6.5.5 


Table  6.5-3.  Cont'd 


POTENTIAL  RECOMMENDED 

COMMAND  OPERATION  _  _  _  COMMAND 


OUTPUT  Define  an  input  or  output  FORMAT 

format. 

Print  a  hard  copy.  PRINT 


OVERWRITE  Enter  data  within  an  input  or  OVERPRINT 

output  format  so  as  to  erase 
and  replace  existing  infor¬ 
mation. 


PAGE 


Page  forward. 


PAGE  AHEAD 


Page  backward. 


PAGE  BACK 


PAGE  AHEAD  Page  forward. 


PAGE  AHEAD 


PAGE  BACK 


Page  backward. 


PAGE  BACK 


PAGE  BACKWARD  Page  backward. 


PAGE  BACK 


PAUSE  Discontinue  current  operation.  ABORT 

Postpone  processing  indefinitely.  DEFER 

Delay  for  stated  amount  of  time.  DELAY 


Stop  temporarily 


PAUSE 


Table  6.5-3.  Cont'd 


POTENTIAL 

COMMAND 

OPERATION 

RECOMMENDED 

COMMAND 

PRESERVE 

Protect  a  file  or  set  of  infor¬ 
mation  . 

PROTECT 

PREVIOUS 

Page  backward. 

PAGE  BACK 

PRINT 

Enter  data  within  an  input  or 
output  format  so  as  to  erase 
and  replace  existing  infor¬ 
mation  . 

OVERPRINT 

Print  a  hard  copy. 

PRINT 

PROTECT 

Protect  a  file  or  set  of  infor¬ 
mation. 

PROTECT 

PURGE 

Delete  an  existing  file  or  set 
of  information. 

DELETE 

QUIT 

Discontinue  current  operation. 

ABORT 

End  (stop)  all  operations. 

CEASE 

Leave  the  system . 

LOGOFF 

Protect  a  file  or  set  of  infor¬ 
mation. 


READ 


PROTECT 
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Table  6.5-3. 

Cont'd 

POTENTIAL 

COMMAND 

OPERATION 

RECOMMENDED 

COMMAND 

RECOLOR 

Add  color  to  a  displayed  out¬ 
put. 

COLOR 

Intensify  the  existing  color  of  a 
displayed  output. 

INTENSIFY 

Change  the  color  of  a  displayed 
output . 

RECOLOR 

RECORD 

Store  a  file  or  set  of  infor¬ 
mation  on  disk. 

DISK 

Store  a  file  or  set  of  infor¬ 
mation  . 

SAVE 

RECORD  D 

Copy  a  file  or  set  of  infor¬ 
mation. 

COPY 

Store  a  file  or  set  of  infor¬ 
mation  on  disk. 

DISK 

RECORD  T 

Copy  a  file  or  set  of  infor¬ 
mation. 

COPY 

Write  a  file  or  set  of  infor¬ 
mation  on  tape. 

WRITE 

REDUCE 

Perform  the  mathematical  opera¬ 
tion  of  subtraction. 

SUBTRACT 

KKKARJC 


Add  reziarks  to  a  file  or  st--.  of  CO KJtKfiT 


Table  6.5-3.  Cont'd 


POTENTIAL  RECOMMENDED 

COMMAND _ OPERATION _ COMMAND 

REMOVE  Delete  an  existing  file  or  set  DELETE 

of  information. 

Exclude  a  piece  of  information  OMIT 

from  a  report. 

Delete  a  piece  of  information  REMOVE 

from  a  file  or  set  of  infor¬ 
mation. 


REPEAT 


Copy  a  file  or  set  of  infor-  COPY 

mat ion . 


REPLY  Acknowledge  a  message  from  the  ACKNOWLEDGE 

CPU  or  another  terminal. 

Request  a  reply  from  the  CPU  REPLY 

or  another  terminal. 


REPORT 


Define  an  input  or  output  FORMAT 

format. 


REQUEST  Indicate  a  file  or  set  of  GET 

information  to  work  with. 


RESPOND  Request  a  reply  from  the  CPU  REPLY 

or  another  terminal. 


RETAIN 


Store  a  file  or  set  of  infor-  DIS" 

nation  on  disk. 


Table  6.5-3.  Cont'd 


POTENTIAL 

COMMAND 


OPERATION 


RECOMMENDED 

COMMAND 


Call  up  and  use  a  specific 
procedure/program . 


EXECUTE 


Store  a  file  or  set  of  infor¬ 
mation  on  disk. 

DISK 

Protect  a  file  or  set  of  infor¬ 
mation  . 

PROTECT 

Store  a  file  or  set  of  infor¬ 
mation. 

SAVE 

Copy  a  file  or  set  of  infor¬ 
mation  from  one  storage  type 
to  another  (e.g.,  tape  to 
disk,  disk  to  tape) . 

TRANSCRIBE 

write  a  file  or  set  of  infor¬ 
mation  on  tape. 

WRITE 

SCHEDULE 


Print  schedule/calendar. 


CALENDAR 


SCREEN 

Screen  out  specified  types  of 
information  from  a  file  or 
set  of  information. 

FILTER 

Screen  out  specified  types  of 
information  to  be  assimilated 
in  a  file  or  set  of  infor¬ 
mation. 

SCREEN 

SEARCH 


Kind  a  designated  portion  of  a 
file  Ci.e.,  data  within  a 
file) . 

Find  designated  file. 


SEARCH 
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POTENTIAL  RECOMMENDED 

COMMAND _ OPERATION _ COMMAND 

SEEK  Find  a  designated  portion  of  a  FIND 

file  (i.e.,  data  within  a 
file) . 

Find  designated  file.  SEARCH 


SELECT  Indicate  a  file  or  set  of  GET 

information  to  work  with. 

Select  and  activate  a  computer-  SELECT 

controlled  device. 


SEPARATE 


Perform  the  mathematical  opera¬ 
tion  of  division. 

Screen  out  specified  types  of 
information  from  a  file  or 
set  of  information. 

Screen  out  specified  types  of 
information  to  be  assimilated 
in  a  file  or  set  of  infor¬ 
mation. 

Arrange  data  into  two  or  more 
files  or  sets  of  information - 


DIVIDE 

FILTER 


SCREEN 


SEPARATE 


SEQUENCE 


Arrange  a  set  of  data  in  an  ALPHABETIZE 

alphabetical  sequence. 

Arrange  a  set  of  data  in  a  CHRONICLE 

historical  sequence. 

Arrange  a  set  of  data  in  a  SEQUENCE 

causal-results  sequence. 


Arrange  a  set  of  data  in  a  SERIALIZE 

specified  sequential  order. 

Sort  data  in  a  file  or  set  of 
information . 


SORT 


Table  6.5-3.  Cont'd 


POTENTIAL 

COMMAND 


OPERATION 


RECOMMENDED 

COMMAND 


SERIALIZE 

Arrange  a  set  of  data  in  an 
alphabetical  sequence. 

ALPHABETIZE 

Arrange  a  set  of  data  in  a 
causal-results  sequence . 

SEQUENCE 

Arrange  a  set  of  data  in  a 
specified  sequential  order. 

SERIALIZE 

Display  index  of  all  avail¬ 
able  files  of  information. 


DIRECTORY 


Display  a  report  or  partial 
report  on  the  screen. 


DISPLAY 


Display  the  content  of  a  field. 


SIGNOFF 


Leave  the  system. 


LOGOFF 


SIGNON 


Enter  the  system. 


LOGON 


Screen  out  specified  types  of 
information  from  a  file  or 
set  of  information. 

FILTER 

Screen  out  spocified  types  of 
information  to  be  assimilated 
in  a  filo  or  sot  of  infor¬ 
mation. 

SCREEN 

Arrango  data  into  two  or  more 
files  or  sots  of  information. 

SEPARATE 

Sort  data  in  a  filo  or  set  of 
information . 

SORT 
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Cont'd 

POTENTIAL 

COMMAND 

OPERATION 

RECOMMENDED 

COMMAND 

START 

Activate  a  computer-controlled 
device . 

ACTIVATE 

Call  up  and  use  a  specific 
procedure/program . 

EXECUTE 

STATUS 

Get  system  status. 

STATUS 

STOP 

Discontinue  current  operation. 

ABORT 

Stop  print.  Discontinue 
print  of  file  or  set  of 
information. 

BREAK 

End  (stop)  all  operations. 

CEASE 

Leave  the  system. 

LOGOFF 

STORE 

Store  a  file  or  set  of  infor¬ 
mation  on  disk. 

DISK 

Store  a  file  or  set  of  infor¬ 
mation. 

SAVE 

SUBSTITUTE 

Exchange  one  piece  of  infor¬ 
mation  for  another. 

EXCHANGE 

SUBTRACT 

Decrease  a  counter. 

DECREASE 

Perform  the  mathematical  opera¬ 
tion  of  subtraction. 


SUBTRACT 


6.5-64 


£ 


■\-v 

vy- 

vy* 

®v 


i 

*  **v 
*\v 

W  *  *  . 


I 


N 


>:5 


Table  6.5-3.  Cont'd 


POTENTIAL  RECOMMENDED 

COMMAND  OPERATION _ _ COMMAND _ 


TRANSCRIBE  Copy  a  file  or  set  of  infor-  TRANSCRIBE 

mation  from  one  storage  type 
to  another  (e.g.,  tape  to 
disk,  disk  to  tape) . 

Move  information  from  one  file  TRANSFER 

to  another. 


TRANSFER 


I 

1 


Exchange  one  piece  of  infor-  EXCHANGE 

mation  for  another. 


Move  information  within  a  file  MOVE 

or  set  of  information. 

Copy  a  file  or  set  of  infor-  TRANSCRIBE 

mation  from  one  storage  type 
to  another  (e.g.,  tape  to 
disk,  disk  to  tape). 

Move  information  from  one  file  transfer 

to  another. 


Exchange  the  order  (sequence)  TRANSPOSE 

of  two  pieces  of  information 
within  a  file. 


TRANSFORM 

Transform  full  language  to 
coded  information  state. 

CODE 

Change  data  into  anothor  measure¬ 
ment  form. 

CONVERT 

Transform  coded  information  to 
full  text. 

DECODE 
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POTENTIAL  RECOMMENDED 

COMMAND _ OPERATION _ COMMAND 

TRANSPOSE  Exchange  one  piece  of  infor-  EXCHANGE 

mation  for  another. 

Move  information  within  a  file  MOVE 

or  set  of  information. 

Move  information  from  one  file  TRANSFER 

to  another. 


Exchange  the  order  (sequence) 
of  two  pieces  of  information 
within  a  file. 

TRANSPOSE 

UNDO 

Sever  the  connection  between  a 
peripheral  unit  and  the  CPU. 

DISCONNECT 

UNSAVE 

Delete  an  existing  file  or  set 
of  information. 

DELETE 

UPDATE 

Edit  a  file  or  set  of  infor¬ 
mation. 

EDIT 

USE 

Indicate  a  file  or  set  of 
information  to  work  with. 

GET 

USSR 

Enter  the  system. 

LOGON 

VALIDATE 

Call  up  numeric  data  for 
examination . 

AUDIT 

LJf 


Establish  data  or  set  of  infor-  AUTHENTICATE 

mation  as  genuine. 

Provo  as  true  by  presenting  VALIDATE 

other/detailod  information. 

Substantiate  truth  or  authon-  VERIVy 

ticity  by  expertise. 


£ 

► 

t 

L 

k 


i' 


6.5-67 


6.5.5 


Table  6.5-3. 

Cont'd 

POTENTIAL 

COMMAND 

OPERATION 

RECOMMENDED 

COMMAND 

VERIFY 

Call  up  numeric  data  for 
examination . 

AUDIT 

Establish  data  or  set  of  infor¬ 
mation  as  genuine. 

AUTHENTICATE 

Prove  as  true  by  presenting 
other/detailed  information. 

VALIDATE 

Substantiate  truth  or  authen¬ 
ticity  by  expertise. 

VERIFY 

VIEW 

Display  the  content  of  a  field. 

SHOW 

WAIT 

Wait  for  input. 

WAIT 

WRITE 

Store  a  file  or  set  of  infor¬ 
mation  on  disk. 

DISK 

Define  an  input  or  output 
format. 

FORMAT 

Enter  data  within  an  input  or 
output  format  so  as  to  erase 
and  replace  existing  infor¬ 
mation  . 

OVERPRINT 

Print  a  hard  copy. 

PRINT 

Copy  a  file  or  set  of  infor¬ 
mation  from  one  storage  type 
to  another  (e.g.,  tape  to 
disk,  disk  to  tape). 

TRANSCRIBE 

Write  a  file  or  set  of  infor¬ 
mation  on  tape. 

WRITE 

Display  the  content  of  a  field. 

SHOW 
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POTENTIAL  RECOMMENDED 

COMMAND _ OPERATION _  COMMAND 


WRITE  TO  TAPE 


Write  a  file  or  set  of  infor-  WRITE 

mation  on  tape. 


W  2  DX  Store  a  file  or  set  of  infor-  DISK 

mation  on  disk. 


W  2  TO 


Display  the  content  of  a  field.  SHOW 


Write  a  file  or  set  of  infor¬ 
mation  on  tape. 


W  2  TP 


WRITE 


SECTION  7.  ERROR  HANDLING 


This  section  explores  the  methods  and  results  of  designing  the  human- 
computer  interface  to  minimize  the  occurrence  and  impact  of  error  by  and  through 
the  user/operator.  Techniques  for  minimizing  the  error  recovery  time  and 
process  complexity  are  presented.  The  guidelines  encompass  the  following 
topics : 

1.  Error  Feedback — deals  with  techniques  for  informing  the  user/ 
operator  that  an  error  has  been  detected  by  the  system. 

2.  Error  Correction  and  Recovery — provides  methods  by  which  the 
user/operator  can  remove/correct  an  error  with  minimum  system 
downtime  or  hesitation. 


7.1  Error  Feedback 


7.1.1  DEFINITION 

Error  feedback  consists  of  messages  from  the  system  software  to  the  user/ 
operator  which  indicate  that  an  error  has  occurred.  This  subsection  deals  with 
the  ways  that  the  system  can  provide  error  feedback  to  help  the  user/operator 
understand  the  naturG  and  cause  of  the  error. 


7.1-1 


7.1.2 


7.1.2  APPLICATIONS  FOR  ERROR  FEEDBACK 

Error  feedback  is  required  any  time  the  system  detects  an  error.  Appli¬ 
cations  for  error  feedback  include: 

a.  Notification  of  illegal  entry.  Illegal  entries  are  those 
entries  in  which  the  user's/operator's  input  does  not  match 
ary  of  the  items  in  a  list  of  legal  entries  for  the  data 
field,  or  is  outside  the  range  of  permissible  numeric  values. 

EXAMPLE:  An  artillery  command  and  control  system  permits  the 
following  entries  for  type  of  shell:  ARMOR  PIERCING,  BIO¬ 
LOGICAL,  ILLUMINATION  (FLARE) ,  FRAGMENTATIO!  GAS/CHEMICAL, 
INCENDIARY,  NUCLEAR,  and  SMOKE.  The  full  name  may  be 
entered,  or  the  following  abbreviations  may  be  used:  ARM, 

BIO,  ILL,  FRA,  GAS,  INC,  NUC,  and  SMO,  respectively.  These 
are  the  only  entries  for  shell  type  recognized  by  the  system. 

Thus,  an  entry  of  "FRG"  for  FRAGMENTATION,  for  examole, 
would  be  treated  as  an  illegal  entry. 

EXAMPLE:  An  armor  d’"*' sion's  command  and  control  support 
system  accepts  any  .  ical  value  between  0  and  216,  inclu¬ 
sive,  for  the  numiter  tasks  on  tanks  on  hand.  An  entry  of 

234  would  therefore  be  treated  as  au  jilegal  entry. 

b.  Notification  of  omitted  data.  Omissions  of  required  data, 
occur  when  the  user/operator  neglects  to  enter  data  into  a 
mandatory  field  or  subfield. 

EXAMPLE;  In  a  command  and  cortrol  system,  certain  messages 
have  a  field  for  a  date-time  group  specifying  the  data  and 
time  that  the  message’s  contents  will  become  effective. 

Failure  to  enter  data  in  this  field  is  an  omission  error. 

c.  Notification  of  insertion  of  extraneous  data.  Insertion  of 
an  extraneous  parameter  occurs  when  a  user/operator  enters 
data  in  a  field,  or  parameters  in  a  command,  in  addition  to 
the  data/parameters  that  are  required. 

EXAMPLE:  In  a  personnel  accounting  system,  only  the  last 
four  digits  of  the  soldier's  SSN  are  required  to  retrieve 
that  soldier's  data.  If  the  user/operator  enters  the  soldier’s 
name  as  well  as  the  last  four  digits  in  response  to  the  prompt 
for  the  last  four  digits,  the  system  treats  the  entry  as  an 
insertion  error. 

d.  Notification  of  field  length  violation.  Field  length  errors 
occur  when  the  user/operator  either  enters  too  few  characters 
or  too  many  characters  in  a  data  field. 

EXAMPLE:  In  the  personnel  accounting  system  mentioned  under 
"c"  above,  entering  the  entire  SSN  would  constitute  a  field 
length  error. 
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EXAMPLE:  In  the  artillery  command  and  control  system  mentioned 
under  "a"  above,  entering  "A"  instead  of  "ARM"  to  designate 
ARMOR  PIERCING  shells  would  constitute  a  field  length  error. 

e .  Notification  of  incorrect  sequence  of  data  entry.  Incorrect 
sequence  errors  occur  when  the  user/operator  enters  the  correct 
number  of  data  elements  for  a  data  field,  or  the  correct  number 
of  command  parameters,  and  each  individual  element  or  para¬ 
meter  is  correct,  but  their  order  is  incorrect. 

EXAMPLE:  In  an  intelligence  information  processing  systems, 
most  command >  require  multiple  parameters  in  a  specified  order. 
For  example,  to  print  the  first  50  records  in  a  data  file 
named  WRNG.DAT,  using  a  predefined  format  named  "3,"  the  user/ 
operator  must  enter: 

GET  FILE  WRNG.DAT,  LIST,  FMT3,  SI,  E50 

Any  other  order  of  parameters  is  treated  as  an  illegal  sequence 
error.  For  example,  the  following  is  an  illegal  sequence 
error: 

GET  FILE  WRNG.DAT,  FMT3,  LIST,  Si,  E50 

f.  Notification  of  contingency  violation.  Contingency  violations 
occur  in  situations  where  entering  data  in  one  optional  field 
causes  a  requirement  for  a  subsequent  entry  in  another  field. 
The  contingency  error  occurs  when  the  user/operator  enters 
data  in  the  first  field  but  not  in  the  second  field. 

EXAMPLE:  In  a  tactical  command  and  control  system,  entering 
data  about  individual  weapon  systems  is  optional.  However, 
if  the  user /operator  enters  data  in  the  "WEAPON  SYSTEM"  field 
(e.g.,  M60A1) ,  then  the  number  of  weapons  on  hand  must  also  be 
entered.  If  neither  "WEAPON  SYSTEM"  nor  "ON  HAND"  is  entered, 
then  no  error  exists.  If,  on  the  other  hand,  the  user/operator 
enters  data  in  the  "WEAPON  SYSTEM"  field  but  does  net  enter 
data  in  the  "ON  HAND"  field,  the  system  encounter,;  a  contin¬ 
gency  violation. 

g.  Notification  of  association  violation.  Association  violations 
occur  when  the  user/operator  enters  two  separate  data  items 
which,  taken  together,  don't  make  sense.  This  error  also 
occurs  when  the  user/operator  enters  a  single  data  item  which, 
when  associated  with  a  previously  stored  item,  doesn't  make 
sense . 

EXAMPLE:  In  associating  a  "mover"  and  a  "shooter"  in  an 
intelligence  information  processing  system,  the  user/operator 
enters  "152mm"  in  the  "SHOOTER"  field  and  "PT76"  in  the 
"MOVER"  field.  Since  the  "PT76  is  equipped  with  a  76mm  gun, 
the  two  data  entries  are  logically  conflicting. 
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EXAMPLE:  An  intelligence  information  processing  system  uses 
a  graphics  display  to  show  the  locations  of  terrain  and 
cultural  features,  and  other  relevant  data.  Users/operators 
add  symbols  to  the  display  by  placing  a  graphics  cursor  at 
the  appropriate  location  on  the  screen  and  then  choosing  the 
appropriate  symbol.  The  system  then  checks  the  symbol  and 
location  for  likelihood.  For  example,  if  the  user/operator 
placed  a  command  post  within  the  area  of  a  lake,  the  system 
would  treat  this  attempt  as  an  illegal  entry. 
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7.1.3  BENEFITS  OF  ERROR  FEEDBACK 


Benefits  obtained  by  providing  well-deeigned  error  feedback  include: 


Reducing  error  rates,  by  minimizing : 


1.  The  number  of  times  a  user/operator  will  unknowingly 
repeat  an  error  if  feedback  is  not  provided. 


2.  The  number  of  times  a  user/operator  will  repeat  an 

error  while  trying  to  make  corrections  on  the  basis  of 
inadequate  feedback. 


3.  The  user ' s/operator*s  frequency  of  error  commission  due 
to  learning  to  avoid  errors  on  the  basis  of  informative 
feedback  when  errors  occur. 


Increasing  system  throughput  rates,  by  minimizing : 


1.  The  time  required  for  users/operators  to  look  up  error 
codes  in  off-line  manuals. 


2.  The  time  required  for  users/operators  to  understand  the 
nature  and  cause  of  errors. 


The  time  required  for  users/op^rators  to  determine  what 
action  to  take  to  correct  errors. 


Reducing  training  requirements,  as  affected  by; 


1.  Reduced  need  to  train  users/operators  in  associating 
error  codes  with  error  conditions. 


Reduced  need  to  train  users/operators  in  error  diagnostic 
procedures . 
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7.1.4  METHODS  FOR  ERROR  FEEDBACK 


Basically,  one  method  is  appropriate  for  virtually  all  error  feedback 
situations,  though  its  implementation  differs  from  one  application  to  another. 
The  method  consists  of: 

a.  An  alarm  to  notify  the  user/operator  that  an  error  has  occurred. 

b.  An  error  code  number  referring  to  off-line  documentation. 

c.  An  option  to  obtain  a  more  detailed  explanation  of  the  error. 

e.  A  detailed  description  of  the  error. 

Examples  of  implementations  of  this  method  for  each  application  described  in 
Section  7.1.2  are  provided  below. 

a.  Illegal  entries.  In  the  hypothetical  artillery  command  and 
control  system  used  to  illustrate  illegal  entries  in  Section 
7.1.2,  the  only  legal  entries  for  shell  type  consisted  of  three- 
character  abbreviations  or  the  full  name  of  the  shell  type. 

If  the  user/operator  entered,  say,  "FRAG"  instead  of  "FRA" 
or  "FRAGMENTATION",  the  system  would  respond  with  an  audible 
"been"  and  the  following  display: 

SYSTEM  PROMPT  AND  ] 

USER/OPERATOR 
RESPONSE  J 


ERROR  FEEDBACK 


If  the  user/operator  now  remembers  what  constitutes  a  legal 
entry  for  shell  types,  the  system  allows  another  attempt  to 
make  a  legal  entry.  On  the  other  hand,  if  the  user/operator 
has  forgotten  why  "FRAG"  is  not  a  legal  entry,  then  pressing 
the  ENTER  key  produces  the  following  display: 
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SHELL  TYPE  CAN  BE  ENTERED  IN  EITHER  OF  THE  FOLLOWING  WAYS: 

1 .  A  3-LETTER  ABBREVIATION 

2.  THE  FULL  HANE  OF  THE  SHELL  TYPE 


“FRAG"  IS  NOT  A  3-LETTER  ABBREVIATION. 
“FRAG"  IS  NOT  A  FULL  NAME. 


IF  YOU  WANT  TO  SEE  THE  LEGAL  ENTRIES  FOR  SHELL  TYPE,  PRESS  “ENTER. 


Once  again,  the  user/operator  is  permitted  to  attempt  a  legal 
entry,  if  desired.  Or,  if  still  unsure  what  constitutes  a 
legal  entry,  the  user/operator  can  press  the  ENTER  key  to  see 
a  list  of  the  available  legal  entries. 

Omitted  data.  In  the  hypothetical  command  and  control  system 
illustrating  omitted  entries  in  Section  7.1.2,  certain  messages 
required  that  the  user/operator  specify  the  date-time  group 
when  the  message  would  become  effective.  Failure  to  enter 
data  in  that  field  would  result  in  the  following  display: 


ERROR  NUMBER  E29: 

NO  ENTRY  MADE  IN  EFF-OTG  FIELD 


IF  YOU  WANT  MORE  INFORMATION,  PRESS  "ENTER." 
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If  the  user/operator  presses  the  ENTER  key,  the  system  provides 
a  more  detailed  explanation: 


THE  EFF-OTG  TELLS  THE  SYSTEM  WHEN  YOUR  t€SSAG£  HILL  6EC0*  EFFECTIVE. 
THIS  FIELD  REQUIRES  AN  ENTRY  SO  THAT  INFORMATION  IN  THE  MESSAGE  CAN 
8E  USED  AT  THE  PROPER  TIME.  YOU  WON'T  ENTER  A  OATE-TIIC  GROUP,  SO 
THE  SYSTEH  OOESN'T  KNOW  WHEN  THIS  MESSAGE  WILL  BECOME  EFFECTIVE. 


Extraneous  data.  In  the  hypothetical  personnel  accounting 
system  illustrating  extraneous  parameter  errors  in  Section 
7.1.2,  the  user/operator  might  enter  "JONES,  5555"  in  response 
to  a  request  for  the  last  four  digits  of  the  serial  number. 

The  system's  prompt,  the  user's/operator's  response,  and  the 
system's  error  feedback  might  appear  as  follows ; 


LAST-FOUR-SSN:  J0NES.5555 


ERROR  NlfBEK  S37: 

‘JONES, 5555"  CONTAINS  TOO  MANY  PARAMETERS  FOR  THE  LAST-FOUR-SSN  FIELD. 


IF  YOU  WANT  MORE  INFORMATION,  PRESS  ‘ENTER."' 
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A  request  for  more  information  would  produce  the  following 
display: 


THE  LAST-FOUR- S$N  FIELD  CONTAINS  THE  LAST  FOUR  DIGITS  OF  A  SOLDIER'S 
SOCIAL  SECURITY  NUCER.  NO  OTHER  INFORMATION  IS  REQUIRED  IN  THIS 

fiao. 


“JONES, 5555”  CONTAINS  DATA  IN  ADDITION  TO  THE  LAST  FOUR  DIGITS  OF  A 
SOLDIER'S  SOCIAL  SECURITY  NUCER. 


Field  length  violation.  In  the  hypothetical  artillery  command 
and  control  system  used  to  illustrate  illegal  entries  in 
Section  1.1.2,  the  user/operator  must  enter  either  a  three- 
character  abbreviation  or  a  full  name  to  specify  shell  type. 
Thus,  entry  of  a  single  character  would  constitute  a  field 
length  error.  The  system's  initial  response  might  be  as 
shown  below: 


ENTER  SHELL  TYPE:  A 


ERROR  NUCER  227: 


SHELL  TYPE  REQUIRES  AT  LEAST  J  LETTERS 


IF  YOU  RANT  TO  SEE  LEGAL  ENTRIES  FOR  SHELL  TYPE,  PRESS  “ENTER. 
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A  request  for  additional  information  would  produce  the  following 
display : 


THE  GET  FILE  CCK4WN0  REQUIRES  T11E  FOLLOWING  PARAICTERS: 

1.  FILE  NM£ 

2.  OPERATION 

A.  SHOW  (TO  DISPLAY  DATA  RECORDS  ON  THE  CRT  SCREEN) 
8.  LIST  (TO  PRINT  DATA  RECORDS  ON  THE  PRINTER) 

3.  FORMAT  NJUC 

4.  START  (FIRST  RECORD  TO  BE  RETRIEVED) 

5.  END  (LAST  RECORD  TO  BE  RETRIEVED) 

THE  FORM  OF  THE  GET  FILE  COHIAND  IS: 

GET  FILE  (FILE  NAME).  (SHOW  OR  LIST).  (FIFTH),  (SXH).  (E HI) 
PARAMETERS  MUST  BE  ENTERED  IN  THE  ORDER  SHOWN. 


Contingency  violation.  In  the  hypothetical  command  and  control 
system  used  to  illustrate  contingency  violations  in  Section 
7.1.2,  entering  data  in  the  "WEAPON  SYSTEM"  and  "ON  HAND"  fields 
is  optional.  However,  if  an  entry  is  made  in  the  "WEAPON  SYSTEM 
field,  then  an  entry  is  mandatory  in  the  "ON  HAND"  field.  If 
the  user/operator  entered,  say,  "M60A1”  in  the  “WEAPON  SYSTEM" 
field  but  made  no  entry  in  the  "ON  HAND"  field,  then  the 
system  might  respond  as  follows: 


ERROR  RIMER  L71; 

•H50A1*  ENURED  IN  WEAPON  SYSTEM  FIELD  BUT  HO  ENTRY  HIDE  U  ON  HAND 
HELD. 


If  YOU  WAN!  MORE  INFORMATION.  PRESS  'ENTER. * 


e«KM  Nint  a  m-. 

amuo  post  s ywa  mao  in  uut. 

If  you  UNI  HQ82  IWO««7ION.  P*SSS  *|NT£B. 
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7.1.5  RECOMMENDATIONS  FOR  ERROR  FEEDBACK 

a.  Do  not  require  the  usur/operator  to  translate  error  feedback 
messages . 

b.  Do  not  use  computer  jargon  (e.g.,  "SYNTAX  ERROR/"  "OUT  OF 
RANGE  ERROR")  in  error  messages.  Instead,  explain  what  error 
condition  exists.  (See  examples  in  Section  7.1.4.) 

c.  Always  repeat  the  user ' -/operator ' s  entry  and  the  data  field 
label  in  error  message  (e.g.,  "FRAG  IS  NOT  AN  ACCEPTABLE 
ENTRY  FOR  SHELL  TYPE") . 

d.  Allow  the  user/operator  to  control  the  amount  of  detail  in 
error  messages,  progressing  from  brief  messages  to  more 
extensive  explanations  at  the  user's/operator's  option. 

e.  Do  not  present  error  numbers  or  codes  alone;  provide  at  least 

a  brief  explanation  of  the  error  along  with  the  number  or  code. 

f.  Provide  off-line  documentation  of  all  error  messages  keyed 
to  the  error  number  or  code;  but  do  not  force  the  user/ 
operator  to  consult  off-line  documentation  to  diagnose  errors. 
Use  off-line  documentation  to  provide  additional  information, 
not  as  a  “translator”  for  obscure  feedback. 

g.  If  system  functions  involve  support  to  subjective  decision 
making,  prompt  the  user/operator  to  consider  information 
that  has  been  overlooked. 

h.  When  the  system  detects  missing  data,  prompt  the  user/operator 
to  enter  the  required  data  rather  than  use  default  data. 

i.  Provide  error  feedback  as  soon  as  possible  after  the  error 
occurs. 

j.  Do  net  assign  blame,  use  patronising  lang  ^age,  or  attempt  to 
be  humorous  in  error  messages.  Phrase  error  messages 
politely. 

k.  Present  error  information  in  a  consistent  location  on  the 
display  device. 
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7,2  Error  Correction  and  Recovery 


7.2.1  DEFINITION 

Error  correction  and  recovery  deals  with  the  process  and  techniques  used 
to  correct  errors  and/or  results  of  the  system  attempting  to  process  erroneous 
data.  The  errors  may  be  due  to  faulty  user/operator  technique  or  the  correct 
entry  of  faulty  information.  Error  correction  and  recovery  includes  resumption 
of  terminal  operation  after  a  short  professing  halt,  as  well  as  recovery  from 
system  outage  due  to  a  software  "crash.1* 
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7.2.2  APPLICATIONS  FOR  ERROR  CORRECTION  AND  RECOVERY 

The  error  correction/recovery  task  is  the  final  step  in  the  error  detection/ 
feedback/correction  process.  Whereas  error  detection  and  feedback  involve  the 
machine  side  of  the  software  interface,  error  correction  requires  reaction  from 
the  user/operator .  The  user/operator  takes  steps  in  response  to  the  error 
notation  and  message  provided  through  the  error  feedback  process.  Applications 
fcr  the  error  correcticn/recovery  procedure  are  to  correct  the  errors  and 
error  conditions  identified  by  error  detection.  In  brief,  these  are: 

a.  Entry  of  special  codes,  passwords,  and  identifications  by  the 
user/operator . 

b.  Entry  of  information  through  keyboard,  voice,  or  other 
direct  means  by  the  user/operator. 

c.  Processing  of  information  involving  stored  or  file  data 
and  producing  a  usable  output. 


7.2.3  BENEFITS  OF  ERROR  CORRECTION  AND  RECOVERY 


Benefits  associated  with  well  designed  error  correction  and  recovery 
procedures  include: 

a.  Reduced  error  rates,  by  minimizing: 

1.  The  number  of  attempts  required  by  the  user/operator  to 
correct  errors. 

2.  The  number  of  attempts/steps  taken  by  the  user/operator 
to  complete  the  task. 

b.  Increased  system  throughput  rates,  by  minimizing: 

1.  The  time  required  to  correct  an  error. 

2.  The  time  required  to  repeat  processing. 

3.  The  time  required  for  accessing  system  references. 

c.  Improved  training  of  users/operators,  as  affected  by: 

1.  Reduction  in  the  complexity  of  error  correction 
instructions . 

2.  Reduction  in  the  time  to  instruct  versus  on-the-job 
experience. 
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7.2.4  METHODS  FOR  ERROR  CORRECTION  AND  RECOVERY 


Methods  for  error  correction  and  recovery  are  affected  by  the  error  feed¬ 
back  capability  of  the  system.  The  error  correction  task  is  strongly  influenced 
by  the  message  and  options  provided  by  error  feedback.  The  assumption  made  for 
the  source  of  error  feedback  information  (a  CRT,  VDU,  or  hardcopy  device)  is 
continued  for  error  correction.  Tutorial  advice  can  be  called  up  by  the  user/ 
operate-  by  responding  to  a  prompt  to  press  "ENTER." 

a.  Data  field (s)  re-entry.  This  is  the  simplest  and  the  most 

frequently  used  method  for  error  correction.  In  this  method, 
the  system  has  detected  the  error,  informed  the  user/operator, 
cleared  the  erroneous  data  field,  backspaced,  and  awaits  the 
user's/operator’s  next  attempt.  The  user/operator  enters  the 
correct  value  in  the  data  field  using  the  error  message  and 
knowledge  of  the  system.  No  externa.,  or  system-supplied  data 
are  necessary. 

EXAMPLE: 

SYSTEM  PROMPT  AND 
USER/OPERATOR 
RESPONSE 


ERROR  FEEDBACK 


ENTER  SHELL  TYPE:  FRAG 

ERROR  NUNBER  134: 

"FRAG”  IS  NOT  AN  ACCEPTABLE  ENTRY  FOR  SHELL  TYPE. 

IF  YOU  WANT  MORE  INFORMATION,  PRESS  “ENTER." 


b.  Data  field(s)  re-entry  with  system-generated  assists  (HELPs). 
This  method  of  error  correction  and  recovery  starts  with  the 
error  feedback  message  and  the  user's/operator's  response  to 
it.  This  method,  however,  is  more  complex  in  that  it  does 
not  rely  entirely  on  the  error  message,  example,  or  user/ 
operator  skill.  In  this  method,  the  user/operator  has  the 
option  of  calling  on  system-generated  assists.  This  method 
takes  longer  than  straight  data  re-entry  due  to  the  extra 
step,  but  offers  the  advantage  of  an  on-line  reference, 


This  error  message  was  received  by  the  user/operator  while 
attempting  to  schedule  an  artillery  barrage  on  given  coor¬ 
dinates  at  the  time  of  the  1710H. 

The  user/operator  must  now  access  the  history  file  to  deter 
mine  if  friendly  troops  are  near  the  coordinates,  what  unit 
they  belong  to,  and  how  to  contact  them  for  verification. 

If  the  troops  are  in  too  close  proximity  to  the  impact  area 
the  mission  will  have  to  be  cancelled  or  rescheduled. 

Using  the  information  "friendly  forces"  and  “23  x  14  x  2N  - 
114  x  29  x  16W, "  user/operator  accesses  the  history  file 
to  find: 


COWANT  e,  BATTALION  1-45 

LOCATION  23  x  14  x  2N  x  114  X  29  X  I IN' 

TIME:  23/03/82  -  1400H 


The  information  verifies  the  conflict,  but  the  information 
is  more  than  3  hours  old.  The  history  file  data  expires 
after  2  hours,  but  no  new  update  has  been  supplied  as  is 
required.  In  fact.  Company  B  is  now  south  of  their  old 
position  and  well  out  of  range.  The  usor/operator  cannot 
override  the  history  file  and  will  have  to  contact  the 
responsible  authority  for  ei thcr  a  redate  of  the  history 
file  or  an  override. 
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7.2.5  RECOMMENDATIONS  FOR  ERROR  CORRECTION  AND  RECOVERY 


a.  Table  7.2-1,  Error  Correction  and  Recovery  Methods  by  Applica¬ 
tions,  presents  a  general  list  of  recommendations  for  selecting 
the  most  effective  error  correction  method  or  methods  given  the 
type  of  error.  To  use  the  table,  first  decide  what  error  type 
applies  to  the  situation  you  are  considering.  Eliminate  any 
error  correction  method  where  a  "4"  appears  as  an  entry.  Select 
the  best  error  correction  method  by  comparing  the  remaining 
error  types  in  view  of  the  specific  error  type  with  which  you 
are  dealing. 
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b.  In  a  repetitive  data  entry  task,  when  data  validation  for  one 
transaction  is  completed,  allow  the  user/operator  to  correct  errors 
before  another  transaction  can  begin. 

c.  Allow  the  user/operator  to  return  easi  *'■<■>  previous  steps  in  a  trans¬ 
action  sequence  in  order  to  correct  er.vi,  *.jr  -axe  any  other 
desired  change. 

d.  When  an  error  occurs  in  a  menu  command  stack,  program  the 
computer  to  indicate  where  it  stopped  processing  and  which 
coceaands  could  not  be  processed. 

e-  To  prompt  for  correction  of  an  error  in  stacked  coceaands, 
display  the  portion  that  needs  to  be  corrected. 

f.  Allow  the  user/operator  to  control  the  amount  of  detail  given 
in  the  explanation  of  error  and  in  the  content  of  the  KELRs. 
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g.  Display  the  changes  in  the  state  or  value  of  altered  items 
which  result  from  user/operator  correction. 

h.  Acknowledge  all  error  corrections  by  the  user/operator  by 
indicating  a  correct  entry  has  been  made  or  by  another  error 
message . 

i.  Require  the  user/operator  to  modify  only  the  incorrect  portion 
of  an  input. 

j.  When  a  data  entry  transaction  has  been  completed  and  errors 
have  been  detected,  permit  direct,  immediate  correction  by 
the  user/operator. 

k.  In  an  interactive  session,  when  a  user/operator  is  prompted 

by  the  system  that  an  error  has  been  detected,  allow  the  user/ 
operator  to  correct  the  error  immediately. 

l.  When  data  entries  or  changes  will  be  nullified  by  an  abort 
action,  require  the  user/operator  to  confirm  the  abort. 

m.  When  a  user/operator  requests  a  HELP,  present  only  the  explan¬ 
atory  information  appropriate  to  the  particular  data  field 
currently  being  addressed. 
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7.2.6  ADVISORY  COMMENTS  ON  ERROR  CORRECTION  AND  RECOVERY 

a.  Data  field  re-entry. 

1.  Provide  automatic  cursor  placement  to  the  first  character 
position  of  the  data  field  to  be  re-entered. 

2.  Allow  the  user/operator,  by  simple  key  operation,  to  recall 
the  erroneous  input  for  evaluation. 

b.  Data  field  re-entry  with  system  generated  assists  (HELPs) . 

1.  Link  HELP  files  or  menus  to  the  specific  error  involved. 

In  this  way,  the  user/operator  will  call  the  relevant 
file  when  requesting  additional  information. 

2.  For  multiple  errors  in  one  entry,  link  the  HELP  files 
to  errors  in  the  order  in  which  they  were  entered. 

stem  or  user/operator  search  and  evaluation. 


1.  Provide  a  step-through  proced 
reference  to  assist  inexperie 
not  provide  them  automatical! 


SECTION  8. 


USER/OPERATOR  CONFIGURATIONS 


Guidelines  in  this  category  address  classes  of  individuals  who  perform 
direct  operational  transactions  with  the  system.  Note  that  these  guidelines 
do  not  address  "end  users, M  those  personnel  such  as  the  commander  and  members 
of  his  staff  who  use  the  system's  products  for  decision  making,  but  who  seldom 
or  never  interact  directly  with  system  capabilities.  The  guidelines  also  do 
not  address  maintenance  personnel  or  functions,  except  insofar  as  they  have 
common  features  with  operational  personnel.  Though  maintenance  is  an 
important  aspect  of  successful  system  operation,  it  is  beyond  the  scope  of 
this  document. 


8.1 


DEFINITION 


User/operatcr  configurations  are  the  combinations  of  personnel,  possess¬ 
ing  similar  or  different  sets  of  skills,  required  to  operate  the  system's 
equipment,  maintain  its  data  stores,  and  generate  its  products.  For  purposes 
of  these  guidelines,  the  terms  “operator"  and  “user"  are  defined  arbitrarily 
as  follows: 

a.  An  “operator"  does  not  personally  make  use  of  the  system's  data 
stores.  An  operator  may  enter  data  into  the  system,  extract 
data  from  the  system,  and  may  manipulate  data  already  stored  in 
the  system.  However,  such  transactions  are  guided  either  by  pre¬ 
pared  paper  forms,  or  by  direct  instructions  of  supervisory 
personnel.  The  operator  seldom  or  never  formulates  queries  or 
instructions  to  the  system  on  individ.gsl  initiative.  Moreover, 
the  operator  seldom  or  never  exercises  independent  judgment  in 
determining  the  type,  content,  or  format  of  system  products. 

b.  A  "user"  may  (and  sometimes  or  even  often  does)  perform  some 
or  most  of  the  transactions  of  an  operator.  However,  the  user 
performs  such  transactions  on  individual  initiative,  in  e»«e 
course  of  some  goal-centered  tas.< .  The  user  normally  receives 
requirements  from  same  source  outside  the  sy ihem  (e.g.,  the  com¬ 
mander,  a  member  of  the  commander's  staff,  or  soma  other 
"customer”  of  the  system.) .  The  user  then  translates  these 
requirements  into  appropriate  menu  selections,  command  statements, 
or  entry  parameters  to  provide  the  appropriate  system  products. 

The  user  also  may  exercise  independent  judgment  in  determining 
the  type,  content,  or  format  of  those  products. 
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8.2  APPLICATIONS  FOR  USER/OPERATOR  CONFIGURATIONS 

Users  and/or  operators  must  be  provided  in  the  system  to  perform  each 
of  the  following  tasks: 


a.  Set  up  equipment  following  a  move. 

EXAMPLE:  A  van-mounted  artillery  support  system  is  shut  down 
and  moved  periodically.  When  the  new  location  is  reached,  pro¬ 
tective  covers  must  be  removed,  cables  must  be  re-attached, 
system  tapes  and/or  disks  must  be  mounted,  etc. 

b.  Logon/Logoff 


EXAMPLE:  The  equipment  operator  must  log  on  to  the  system  before 
performing  initialization  or  other  operational  functions.  Users 
and  other  operators  must  log  on  before  gaining  access  to  system 
capabilities.  Users  and  operators  must  log  off  to  signal  the 
system  that  they  no  longer  need  its  capabilities. 

Initi.  _zo  che  system. 


EXAMPLE:  After  a  move,  a  mobile  command  and  control  system  is 
set  up  and  the  equipment  operator  logs  on.  To  initialize  the 
system,  the  operator  must  set  up  a  "customer"  table,  relating 
each  remote  terminal  to  appropriate  security  levels,  encryption 
devices,  data  bases,  and  categories  of  permissible  messages. 

Coordinate  workstations. 
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EXAMPLE:  In  a  supply  inventory  system,  some  of  the  system's 
remote  terminals  must  be  able  to  communicate  with  certain 
other  terminals,  but  not  with  others.  These  requirements  change 
depending  on  the  specific  functions  being  performed.  The  equip¬ 
ment  operator  must  coordinate  the  various  terminals  to  ensure 
the  necessary  communications  capabilities  and  restrictions. 

e.  Monitor  system  operations. 


EXAMPLE:  In  an  intelligence  information  processing  system,  the 
equipment  operator  must  monitor  equipment  to  ensure  that  the 
central  computer,  tape  drives,  disk  drives,  printers,  and  remote 
terminals  are  operating  properly.  If  malfunctions  are  detected, 
the  operator  may  perform  repairs  personally,  or  summon  main¬ 
tenance  personnel. 

f.  Enter  data. 


EXAMPLE:  In  a  tactical  command  and  control  system,  most  of  the 
incoming  data  enter  the  system  data  bases  automatically,  as 
digital  signals  from  sensors  or  from  affiliated  systems.  Users/ 
operators  occasionally  enter  data  obtained  from  radio,  tele¬ 
phone,  or  hard-copy  messages. 
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EXAMPLE:  In  a  personnel  accounting  system,  virtually  all  data 
in  the  system's  data  bases  are  entered  by  personnel  operating 
terminals  transcribing  from  prepared  paper  forms. 


Correct  entry  errors. 


EXAMPLE:  In  an  artillery  support  system,  each  data  item  is 
checked  for  validity  immediately  after  entry.  When  an  error 
is  detected,  the  system  provides  immediate  feedback  and  gives 
the  user/operator  an  opportunity  to  correct  the  error. 


EXAMPLE:  In  a  supply  inventory  system,  input  data  are  loaded 
onto  magnetic  tapes  at  a  peripheral  computer.  The  system  checks 
the  data  while  reading  the  tape,  and  generates  a  hard-copy  log 
of  errors  which  is  returned  to  personnel  at  the  peripheral  com¬ 
puter  for  correction. 


h.  Correct  stored  errors. 


EXAMPLE:  An  intelligence  analyst  working  with  a  graphic  display 
discovers  that  a  separate  brigade  has  been  aggregated  into  a 
division.  Using  picking  and  labeling  procedures  appropriate  to 
the  situation,  the  analyst  separates  the  brigade  from  the  divi¬ 
sion  and  identifies  it  correctly. 


i.  Update  stored  data. 


EXAMPLE:  A  command  and  control  support  system  contains  data  on 
the  status  of  weapon  systems  in  the  division.  As  reports  arrive 
concerning  losses  or  replacements,  an  individual  enters  commands 
and  data  needed  to  reflect  the  changes  to  the  data  base. 


j .  Tabulate . 


EXAMPLE:  A  personnel  accounting  system  stores  data  on  all  per¬ 
sonnel  in  a  division.  For  periodic  status  reports,  system 
software  tabulates  officers,  warrant  officers,  and  enlisted 
soldiers,  broken  down  by  combat,  combat  support,  and  combat 
service  support  specialties. 


k.  Aggregate . 


EXAMPLE:  An  intelligence  support  system  includes  software  to 
assign  individual  enemy  entities  such  as  tanks  to  identified 
parent  units,  on  the  basis  of  criteria  supplied  by  the  analyst. 


1.  Calculate. 


EXAMPLE:  An  artillery  support  system  receives  data  on  target 
type  and  position.  Using  this  data  and  information  previously 
stored  in  effects  tables,  meteorological  files,  and  gun  char¬ 
acteristics  files,  the  system  calculates  firing  data  for  each 
battery  in  an  artillery  battalion. 
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m.  Estimate. 


EXAMPLE:  As  data  are  entered/  tabulated,  and  aggregated  accord¬ 
ing  to  analyst  instructions,  the  system  combines  these  data  with 
previously-stored  data  about  enemy  forces.  Based  on  the  results 
of  its  calculations,  system  software  generates  an  estimate  of 
enemy  strength  in  the  sector. 

n.  Superimpose. 


EXAMPLE:  On  the  graphics  screen  of  a  tactical  command  and  con¬ 
trol  support  system,  an  analyst  uses  the  capabilities  of  the 
system  to  place  symbols  and  labels  representing  enemy  forces  on 
a  display  of  terrain  and  cultural  features. 

EXAMPLE:  An  intelligence  analyst  uses  system  commands  to  call 
up  ::  map  display  on  a  graphics  screen.  Using  other  commands, 
the  analyst  then  calls  up  a  software  overlay  of  tactical  boundary 
features  (e.g. ,  Forward  Line  of  Own  Troops,  No  Fire  Line,  etc.). 

o.  Translate. 


EXAMPLE:  Given  a  set  of  information  requirements  by  an  end  user 
(e.g.,  the  G-3),  a  command  and  control  support  system  user  con¬ 
verts  these  requirements  into  specifications  for  system  products. 
That  is,  the  user  describes  the  types  and  amounts  of  information 
that  must  be  retrieved  from  the  system  in  order  to  satisfy  the 
requirements. 

p.  Formulate ■ 


EXAMPLE:  Having  translated  end  user  information  requirements 
into  system  product  specifications,  a  command  and  control  support 
system  user  formulate j  the  sequence  of  commands,  menu  selections, 
pre-formatted  form  entries,  and/or  queries  required  to  perform 
the  data  processing  casks  necessary  to  generate  che  desired  out¬ 
put. 

q.  Choose  a  data  processing  strategy. 

EXAMPLE:  By  using  different  sysvem  capabilities  in  various 
ways,  an  intelligence  analyst  can  generate  an  estimate  of  enemy 
strength  by  any  of  several  command  sequences.  By  interpreting 
end  user  information  requirements  in  light  of  system  character¬ 
istics,  the  analyst  decides  on  the  specific  sequence  to  be  used 
for  the  task. 

r.  Evaluate  results  of  data  processing. 


EXAMPLE:  An  intelligence  analyst  examines  an  enemy  strength 
estimate  generated  by  the  system.  In  light  of  experience  in 
both  intelligence  analysis  gnd  system  operations,  the  analyst 
evaluates  the  estimate.  When  the  analyst  delivers  the  estimate 
to  the  end  user,  the  report  includes  an  opinion  as  to  the 
estimate's  validity. 
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Define  system  parameters. 

EXAMPLE:  On  the  basis  of  evaluating  system  output  products,  an 
intelligence  analyst  determines  that  additional  parameters  should 
be  used  by  the  system  in  generating  an  enemy  strength  estimate. 

The  analyst  instructs  the  system  to  include  those  parameters  in 
its  processing  procedures  and  then  generate  a  new  estimate. 
Depending  on  the  particular  situation  and  the  reasons  for  includ¬ 
ing  the  additional  data,  the  analyst  may  seek  approval  from  higher 
authority  to  include  one  or  more  of  these  parameters  permanently. 

Generate  standard  reports. 

EXAMPLE:  A  supply  inventory  system  generates  a  variety  of  rou¬ 
tine  weekly,  monthly,  and  annual  reports.  Each  such  report  has 
a  single,  standard  format;  thus,  the  Monthly  Consolidation 
Report  always  emerges  from  the  system  in  the  same  format  and 
contains  the  same  data  elements.  To  generate  the  report,  the 
operator  merely  enters  whatever  data  are  required  to  bring  the 
data  base  up  to  date,  then  selects  the  report  name  from  a  menu. 

The  computer  automatically  performs  all  computations  required, 
tabulates  the  data  as  necessary,  and  generates  the  report  in  the 
previously-defined  format. 


Generate  non-standard  reports. 


EXAMPLE:  The  division  commander  lists  the  weapon  systems,  fuel 
types,  ammo  types,  and  personnel  categories  on  which  he  wants 
daily  status  reports.  These  information  types  change  from  time 
to  time,  depending  on  the  mission.  Using  the  command  language 
capabilities  of  the  command  and  control  support  system,  a  user 
specifies  the  data  types  listed  in  the  commander's  guidance. 

The  user  then  instructs  the  system  to  limit  the  retrieval  pro¬ 
cess  to  data  no  more  than  24  hours  old,  and  formats  the  report 
in  a  manner  to  make  it  easily  readable  by  the  G-3  and  commander 
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8.3  BENEFITS  OF  USER/OPERATOR  CONFIGURATIONS 

Careful  consideration  of  user/operator  char?  ...sties,  duties,  and  skills, 
especially  during  early  stages  of  system  design,  will  help  to  assure  an  op¬ 
timum  "mix"  of  the  personnel  types  required  to  perform  the  system’s  various 
functions.  In  addition,  early  consideration  of  these  factors  will  help  to 
avoid  the  situation  in  which  a  system  is  unwittingly  designed  for  a  higher 
level  of  personnel  than  is  readily  available.  More  specifically,  careful 
assignment  of  system  functions  to  appropriate  types  of  users/operators  will: 

a.  Reduce  error  rates: 

1.  By  encourag'  .g  performance  of  tasks  which  are  within 
personnel  capabilities. 

2.  By  eliminating  boredom  and  frustration  on  the  part  of 
personnel  by  assignment  to  tasks  that  challenge  their 
capabilities. 

b.  Increase  system  throughput  rates,  by  enhancing  the  oppor¬ 
tunity  for  personnel  to  perform  tasks  appropriate  to  their 
skills  easily,  confidentially,  and  accurately. 

c.  Increase  job  satisfaction,  as  occasioned  by  confidence  and 
success  of  personnel  performing  tasks  appropriate  to  their 
skills. 
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8.4  METHODS  FOR  IMPLEMENTING  DATA  PROCESSING  APPLICATIONS 

This  subsection  is  headed  "Methods..."  for  consistency  with  other  parts 
of  this  handbook.  However,  that  heading  is  a  misnomer,  because  the  "methods" 
in  this  section  are  actually  descriptions  of  person;,  si  characteristics,  duties, 
and  skills  related  to  system  functions  and  operations.  These  characteristics, 
duties,  and  skills  are  allocated  among  five  categories  of  operators  and  system 
users,  as  described  below. 

a.  Equipment  Operator. 

1.  Relevant  Characteristics:  Equipment  operators  generally 
will  be  lower-ranking  enlisted  personnel,  with  little  or 
no  specialized  training  except  in  computer  operations. 

They  may  have  received  fundamental  training  in  the  functional 
area  (e.g.,  artillery,  armor,  personnel,  supply)  supported  by 
the  system.  However,  their  primary  jobs  will  be  computer 
operations,  and  they  probably  will  have  a  computer- related 
MOS. 

2.  System-Related  Duties:  Equipment  operators  operate  the  com¬ 
puters  and  related  machines  at  the  system's  central  computer 
facility.  They  prepare  the  system  for  moves,  ready  the  sys¬ 
tem  for  operations  after  moves  (including  initialization,  if 
necessary),  provide  equipment  resources  as  required  (e.g., 
mount  and  dismount  magnetic  tapes  and  disks) ,  and  monitor 
the  system  to  ensure  that  equipment  functions  properly. 

Depending  on  the  system's  design,  equipment  operators  also 
may  perform  routine  diagnostic  and  repair  tasks. 

3.  Required  Skills: 

(a)  Equipment  operators  must  know  the  system's  general 
electronic,  electrical,  and  mechanical  characteristics 
only  in  sufficient  detail  to  enable  them  to  disconnect 
and  reconnect  cables  and  perform  otter  tear-down  and 
set-up  tasks  during  moves. 

(b)  They  must  know  how  to  use  foaturos  of  system  terminals 
related  to  logon/logoff,  initialization,  coordination 
of  workstations,  and  monitoring  activities. 

(c)  In  connection  with  (b)  above,  they  must  know  the  sys¬ 
tem's  software  capabilities  related  to  these  activities 
(e.g.,  commands,  menus,  and/or  on-line  forms  to  be 
filled  in  connection  with  the  initialization  procedure). 

(d)  They  need  not  know  functional  capabilities  required  to 
enter,  correct,  nodify,  or  manipulate  data;  or  to  gen¬ 
erate  system  products. 
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(e)  They  need  not  know  the  structures  or  contents  of  data 
bases/  or  of  individual  data  records. 

(f)  They  need  not  know  the  relationships  among  data  records, 
or  among  data  bases. 

b.  Data  Entry  Operator. 

1.  Relevant  Characteristics:  Data  entry  operators  generally  will 
be  lower- ranking  enlisted  personnel.  Normally,  they  will  have 
been  trained  in  the  functional  area  (e.g.,  artillery,  armor, 
personnel,  supply)  supported  by  the  system,  at  least  to  the 
level  of  apprentices  or  clerks.  Indeed,  in  many  systems  they 
will  work  part-time  as  operators  and  part-time  as  apprentices 
or  clerks. 

2.  System-Related  Duties:  Data  entry  operators  transcribe  data 
into  the  system,  either  directly  (i.e.,  on-line)  or  onto  mag¬ 
netic  media  which  are  read  into  the  system  subsequently.  Data 
are  provided  to  the  operator  on  hard-copy  forms,  or  less  fre¬ 
quently  by  voice  via  radio,  telephone,  or  a  speaker  near  the 
data  entry  station.  Data  entry  operators  frequently  will 
generate  routine,  standardized  outputs  (e.g.,  periodic  hard¬ 
copy  reports  with  invariant  formats) . 

3.  Required  Ski 11s i 

(a)  Data  entry  operators  must  know  how  to  operate  relevant 
features  of  terminals  used  for  data  entry  (e.g. ,  alpha¬ 
numeric  keyboard,  numeric  keypad,  function  keys  related 
to  data  entry). 

(b)  Thoy  must  know  functional  capabilities  required  to  log 
on  and  off,  to  identify  types  of  data  to  be  entered 
(e.g.,  personnel  promotion/reclassif ication,  target 
identification,  spare  parts  requisition,  weapon  system 
status) ,  to  enter  data  and  correct  entry  errors,  and 
to  generato  standardized  reports. 

(c)  Thoy  need  to  know  the  structures  of  individual  data 
records,  but  not  the  structures  or  contents  of  data 
bases. 

(d)  They  need  to  know  little  or  nothing  about  the  elec¬ 
tronic,  electrical,  or  mechanical  characteristics  of 
the  system. 

(e)  Thoy  do  not  need  to  know  software  capabilities  required 
to  modify  or  manipulate  stored  data,  or  to  generate 
non-standard  system  products. 

(f)  They  do  not  need  to  know  the  relationships  among 
data  records,  or  among  data  bases. 
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c.  Data  Base  Operator. 

1.  Relevant  Characteristics j  Data  base  operators  normally  will 
be  middle-ranking  enlisted  personnel.  In  addition  to  advanced 
training  in  the  functional  area  (e.g.,  artillery,  armor,  per¬ 
sonnel,  supply)  supported  by  the  system,  they  also  will  have 
accumulated  considerable  experience.  They  may  also  have  con¬ 
siderable  experience  with  the  new  system's  predecessor,  if 
any.  Often,  they  will  divide  their  time  between  system  opera¬ 
tions  and  other  duties  in  the  functional  area. 

2.  System-Related  Duties:  Data  base  operators  basically  perform 
operations  of  the  system's  data  bases  under  supervision.  They 
generally  maintain  the  accuracy  of  data  bases,  correcting 
errors  that  were  not  detected  during  data  entry,  and  updating 
data  stores  as  necessary.  They  also  manipulate  stored  data  and 
generate  non-standardized  (i.e.,  customized)  reports  in 
accordance  with  instructions  from  supervisory  personnel. 

3.  Required  Skills: 

(a)  Data  base  operators  must  be  familiar  with  all  operational 
features  of  the  terminal  used  for  data  base  operations 
(e.g.,  alphanumeric  keyboard,  numeric  keyboard,  all  func¬ 
tion  keys,  graphic  controls). 

(b)  They  must  be  familiar  with  functional  capabilities  re¬ 
quired  to  modify  and  manipulate  stored  data  and  to 
generate  output  reports. 

(c)  They  must  be  familiar  with  software  capabilities  re¬ 
quired  to  log  on  and  off,  and  to  enter  and  correct  data. 

(d)  They  must  be  familiar  with  the  structures  of  individual 
data  records,  and  the  structures  and  contents  of  data 
bases. 

(e)  They  need  know  little  or  nothing  about  the  electronic, 
electrical,  or  mechanical  characteristics  oi  the  system. 

(f)  They  need  not  know  the  relationships  among  individual 
data  records,  or  among  data  bases. 

d.  Data  Base  User. 


1.  Relevant  Characteristics:  Data  base  users  might  be  thought 
of  as  "upgraded"  data  base  operators.  Generally,  they  will 
bo  middle-level  enlisted  personnel.  They  will  have  received 
advanced  training  in  the  functional  area  (e.g.,  artillery, 
armor,  personnel,  supply),  and  will  have  accumulated  sub¬ 
stantial  experience  in  the  functional  area.  They  will  also 
have  had  substantial  experience  with  any  predecessors  of  the 
new  system.  They  normally  will  have  considerable  functional 
duties  outside  the  system,  and  will  use  the  system  as  one  of 
their  tools  in  functional  performance. 
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2.  System-Related  Duties:  Data  base  users  exercise  independent 
judgment  in  translating  system  output  requirements  into  system 
processing  tasks.  They  perform  these  tasks,  and  generate  non- 
standardized  (i.e. ,  customized)  reports  to  satisfy  system 
output  requirements  without  supervision.  Under  supervision, 
they  may  also  perform  decision-related  functions  normally  per¬ 
formed  by  "System  Users"  (described  below) . 

3.  Required  Skills: 

(a)  Data  base  users  must  know  all  relevant  features  of  the 
system's  terminals. 

(b)  They  must  be  familiar  with  all  system  capabilities, 
except  those  required  for  routine  operations  (e.g. , 
initialization) . 

(c)  They  must  know  thoroughly  the  structures  of  individual 
data  records,  and  the  structures  and  contents  of  data 
bases. 

(d)  They  must  be  familiar  with  the  relationships  among 
data  records  and  among  data  bases. 

c.  System  User. 

1.  jusls-ant  Characteristics:  System  users  are  senior  NCOs  or 
offi^re,  They  have  received  most  or  all  formal  training 
a,-'.' Liable  in  the  functional  area  (e.g.,  artillery,  armor, 
personnel,  supply) ,  and  wiU  have  accumulated  extensive 
experience  in  the  functional  area.  If  the  new  system  has 
a  predecessor  system,  they  wil]  have  see.,  among  its  mort 
skilled  users/operators.  The  system  will  bt  but  or,'  of  the 
tools  they  use  in  performing  their  functional  duties. 

2.  System-Related  Duties:  Given  an  “end  user"  requirement 
(e.g.,  a  demand  from  the  commander  for  information  about 
current  enemy  intentions),  the  system  user  will  formulate 
system  output  requirements  that  will  satisfy  the  end  user 
requirement.  The  system  user  may  then  hand  off  the  job 
to  a  data  base  operator,  or  go  ahead  to  translate  system 
output  requirements  in*-o  specific  data  processing  Casks, 
wnlch  may  or  may  not  be  performed  personally.  The  system 
user  will  then  evaluate  the  results  for  conformance  with 
the  end  user  requirement.  If  necessary,  other  data  pro¬ 
cessing  strategies  may  be  chosen,  and  additional  system 
parameters  may  be  defined.  Then,  processing  is  performed 
again  to  generate  more  useful  results. 

3.  Required  .Skills:  The  system  user  combines  all  of  the 
skills  of  other  users/oporators,  particularly  those  of  data 
base  operator  and  data  base  user,  though  at  a  level  of 
greater  expertise. 
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8.5  RECOMMENDATIONS  FOR  USER/OPERATOR  CONFIGURATIONS 


a.  In  deciding  whether  to  automate  a  given  system  function  or  to 
assign  it  to  a  human  being,  consider  the  training  and  skills 
of  the  personnel  who  will  be  available  to  staff  the  system. 

Table  8.5-1  lists  applications  (system  functions)  and  user/ 
operator  types,  and  provides  recommendations  regarding  assign¬ 
ment  of  functions  to  users/operators. 

b.  Do  NOT  assume  that  system  functional  capabilities  can  be  designed 
without  regard  to  user/operator  types.  Find  out  what  kinds  of 
personnel  will  be  available  to  staff  the  system  before  designing 
the  system.  That  is,  before  designing  an  artillery  support  sys¬ 
tem,  check  with  the  Artillery  School  and  other  subject  matter 
experts  about  personnel  availability  in  the  out  years  (instead 
of  assuming,  for  example,  ample  availability  of  experienced 
senior  NCOs) . 

c.  If  a  function  would  force  a  lower-level  user/operator  (e.g., 
a  data  base  operator)  to  perform  above  normal  capabilities 
occasionally,  but  would  force  the  next  higher-level  user/ 
operator  (e.g.,  a  data  base  user)  to  perform  below  normal 
capabilities  occasionally,  assign  the  function  to  the  higher- 
level  user /operator. 

d.  If  a  function  would  force  a  lower-lavel  user/operator  (e.g., 
a  data  base  operator)  to  perform  above  normal  capabilities 
consistently,  but  would  force  the  next  higher-level  user/ 
operator  (e.g.,  a  data  base  user)  to  perform  below  normal 
capabilities  consistently,  redesign  the  function  for  com¬ 
patibility  with  one  type  of  user/oporator. 

e.  Do  NOT  assume  that  additional  training  will  overcome  defi¬ 
ciencies  in  performance  caused  by  inappropriate  assignment 
of  system  functions  to  user/operator  types.  Training  might 
overcome  such  deficiencies,  but  it  probably  won’t.  The  only 
certainty  in  regard  to  this  issue  is  that  adding  training 
will  increase  the  burden  on  the  schools  and  the  using  unit®, 
and  add  to  the  cost  of  the  system  over  its  life. 

f.  When  ©ore  than  one  user/operator  is  logged  onto  tho  system, 
make  sure  that  inputs  by  one  individual  do  not  interfere  with 
any  other  individual's  vo»k.  SrtSPTIQN;  A  higher-level  or 
supervisory  user  may  need  to  transmit  a  priority  message  for 
immediate  execution  by  a  lower-level  or  subordinate  user/ 
operator.  In  this  event,  save  the  entire  task  on  which  the 
latter  individual  is  working  at  the  time  of  interruption,  so 
that  complete  recovery  can  be  made  later.  (See  Section  3.3 
Interrupts  and  Work  Kecovery .) 

g.  When  users/oporators  communicate  vith  each  other  via  on-line 
messages,  always  identify  the  sender  of  a  message. 
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APPLICATIONS  (SYSTEM  FUNCTIONS) 


Appropriate  fund) on,  Cut  only  If  the  user/operator  Is  given  adequate  assistance/supervision. 

Ilonu | I ■/  Inappropriate  function,  but  My  be  performed  occasionally  during  performance  of  more  appropriate  functions. 
Highly  Inappropriate  function:  i eposes  excessive  burden  on  the  user/operator,  or  else  wastes  user/operator  training 


If  a  display  screen  will  be  used  by  more  than  one  user/ 
operator,  provide  a  cursor  for  each  individual. 

Provide  storage  for  separate  personal  files  for  each  user/ 
operator  of  the  system. 

Maintain  a  permanent  record  of  all  messages  sent  from  any 
user/operator  to  any  other. 
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query  methods,  5.1-13  -  5.1-18 
query  structure,  5.2-11  -  5.2-12 
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2.1- 15 

work  recovery,  3.3-10  -  3.3-11 
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applications,  b.1-2 
definition,  6.1-1 
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applications,  1.1-2 
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definition,  1.1-1 

error  rates,  1.1-3 
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transmission  rate,  1.1-10 
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user/operator  characteristics , 
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user/operator  frustration,  1.1-3 
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data  entry,  2.1-2 
definition,  2.1-1 
error  handling,  2.1-2 
error  rates,  2.1-3 
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method?,  2.1-4  -  2.1-10 
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Alphanumeric  displays,  cont’d: 
throughput  rate,  2.1-3 
use,  2-1 

Alphanumeric  messages:  4.1-1  - 

4.1-11 

advisory  comments,  4.1-9  -  4.1-11 

applications ,  4 . 1-2 

benefits,  4.1-3 

definition,  4.1-1 
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4.1- 7 

recommendations ,  4 . 1-8 
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Applications  for: 

abbreviations  and  codes,  6.3-4 
alphanumeric  control  methods, 

1.1- 2 

alphanumeric  displays,  2.1-2  - 

2.1-3 

alphanumeric  messages,  4.1-2 
error  correction  and  recovery, 


Automatic  storage,  interrupts  and 
work  recovery,  3.3-7,  3.3-10  -  3.3-11 

Bar  chart: 

advisory  comments,  2.2-11 
creation,  4.2-4 
graphics  display,  2.2-5 

Benefits  of: 

abbreviations  and  codes,  6.3-5 
alphanumeric  control  methods,  1.1-3 
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alphanumeric  message  composition, 

4.1- 3 

error  correction  and  recovery, 

7.2- 3 

error  feedback,  7.1-5 

full  language,  6.4-3 

glossaries,  6.5-3 

graphics  control  methods,  1.2-8 

graphics  displays,  2.2-4 

graphics  display  composition,  4.2-6 

HELPS,  1.3-4 
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7.2- 2 

error  feedback,  7.1-2  -  7.1-4 
full  language,  6.4-2 
glossaries ,  6.5-2 
graphics  control  methods,  1.2-2  - 

1.2- 7 

graphics  displays,  2.2-2  -  2.2-3, 

4.2- 2  -  4.2-5 
HELPS,  1.3-2  -  1.3.3 
highlighting,  2.3-2  -  2.3-4 
input  unburdening,  3.2-2  -  3.2-3 
interrupts  and  work  recovery, 

3.3- 2  -  3.3.3 

legal  entries,  3.1-2  -  3.1-3 
query  methods,  5.1-2 
query  structure,  5.2-2 
selective  highlighting,  2.3-2  - 

2.3- 3 

standard  terms,  6.2-2 
symbols,  6.1-2 

user/operator  configuration, 

8.2-1  -  8.2  -4 


highlighting,  2.3-4 
input  unburdening,  3.2-4 
interrupts  and  work  recovery, 

3.3-4  -  3.3-5 
legal  entries,  3.1-4 
query  methods,  5.1-3 
query  structure,  5.2-4 
standard  terms,  6.2-3 
symbols,  6.1-3 

user/operator  configuration,  8.3-1 
work  recovery,  3.3-4  -  3.3-5 

Blinking,  highlighting,  2.3-8,  2.3-16 

Boxing,  highlighting,  2.3-9,  2.3-17 

Brightness  control,  highlighting, 

2.3- 5,  2.3-14 

Changed  information,  highligting  of, 

2.3- 2 

Character  font,  highlighting,  2.3-7, 

2.3- 15  -  2.3-16 


vi 


work  recovery,  3.3-2  -  3.3.3 

Arabic  symbols: 

applications,  6.1-2 
definition,  6.1-1 

Arrows,  highlighting,  2.3-9,  2.3-17 

Automatic  operation,  versus  manual, 
8.5-1 


Character  size,  highlighting,  2.3-5, 

2.3-14 

Charts: 

advisory  comments,  2.2-11  -  2.2-13 
creation,  4.2-2 

graphics  display,  2.2-7  -  2.2-9 
symbolic  codes,  6.3-3 


Code  book,  legal  entries,  3.1-10 
Cocie  design: 

considerations  in,  6.3-12  -  6.3-13 
control,  6.3-12 
human  considerations,  6.3-12 
legal  entries,  3.1-2  -  3.1-3, 

3.1- 13 

machine  considerations,  6.3-12 
preferences,  6.3-13 
recommendations,  6.3-12  -  6.3-15 
rules,  6.3-13  -  6.3-15 

Code  length: 

chunking,  6.3-13 
discriminability ,  6 . 3-14 
user/operator  error,  6.3-15 

Codes:  (see  also  abbreviations) 

6.3-1  -  6.3-15 
applications,  6.3-4 
benefits,  6.3-5 
consistency,  6.3-14 
definition,  6.3-1 
examples,  6.3-2 
glossary,  6.5-5 
legal  entries,  3.1-15,  3.1-16 
methods ,  6 . 3-6 
query  structure,  5.2-12 
recommendations,  6.3-12  -  6.3-15 
unburdening  of  input,  3.2-10, 

3.2- 25 

versus  full  language,  6.3-3,  6.4-5 

6.3- 13 

Color: 

codes,  6.3-3,  6.3-15 
discriminatbility ,  6.3-15 
highlighting,  2.3-8,  2.3-16 

Columnar  data,  alphanumeric  displays 

2.1- 13 

Command  entry,  input  unburdening, 

3.2- 2 

Command  file: 

query  methods,  5.1-8,  5.1-17 
query  structure,  5.2-9 

Command  language  dialog: 
advisory  comments,  1.1-14 
alphanumeric  control  method,  1.1-7 

Command  macro: 

input  unburdening,  3.2-12,  3.2-27 
query  methods,  5.1-8,  5.1-17  - 

5.1-18 

query  structure,  5.2-9 


Command  stack: 

data  transmission  rate,  1.1-13 
error  correction,  7.2-7 
menu  size,  1.1-13 
query  methods,  5.1-15 
unburdening  of  input,  3.2-21 

Command  string,  unburdening  of  input, 

3.2-14 

Commands:  (for  individual  commands, 
see  recommended  commands  versus 
operation  versus  potential  commands, 

6.5-6  -  6.5-69) 
alphanumeric  control  methods, 

1.1-9  -  1.1-15 
complexity  of,  1.2-24 
glossary  compilation,  6.5-5 
glossaries  of,  6.5-6  -  6.5-69 
multiple  screen  displays,  1.2-24 
number  of,  1.1-9,  1.2-24,  1.3-9  - 

1.3-11 

potential  commands,  by  operation, 
by  recommended  command,  6.5-33  - 

6.5- 69 

operation,  by  potential  commands, 
by  recommended  command,  6.5-19  - 

6.5- 32 

recommended,  by  operation,  by  poten¬ 
tial  commands,  6.5-6  -  6.5-18 
selection  of,  1.2-2 
standard  terms,  6.2-2 
transmission  rate,  1.1-10 
usage  rate,  1.1-9,  1.2-24 

Comments  (see  advisory  comments) 

Communication  receipt,  interrupts 
and  work  recovery,  3.3-2 

Computer-generated  data: 
data  entry,  3.2-20 
input  unburdening,  3.2-5,  3.2-20 
query  methods,  5.1-11 

Computer  jargon,  error  feedback, 

7.1-14 

Computer-propagated  data? 
data  entry,  3.2-20 
input  unburdening,  3.2-5,  3.2-20 

Concurrent  tasks,  interrupts  and  work 
recovery,  3.3-3 

Consistency,  terminology,  6.4-5 
Contractions,  full  language,  6.4-5 


h 

t 
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Control  keys,  graphics  control 
method,  1.2-17  -  1.2-18 

Control  methods:  1-1  -  1.3-13 
alphanumeric,  1.1-1  -  1.1-16 
graphics,  1.2-1  -  1.2-29 
HELPS,  1.3-1  -  1.3-13 
scope,  1-1 

Cursor: 

control  keys,  1.2-18 
cross-hair  digitizing,  1.2-17 

Cursor  control: 

alphanumeric  message  composition, 

4.1- 7 

graphics  displays,  4.2-9 

input  unburdening,  3.2-9,  3.2-24  - 

3.2- 25 

query  methods,  5.1-7,  5.1-16  - 

5.1-17 

query  structure,  5.2-8 
user/operator  configuration,  8.5-3 

Cursor  control  dialog: 
advisory  comments,  1.1-14 
alphanumeric  control  method,  1.1-7 

Cursor  control  keys,  graphics 
control  method,  1.2-17  -  1.2-18 

Cursor  HOME  position,  input  unbur¬ 
dening,  3.2-19 

Data  association,  error  feedback, 

7.1-3  -  7.1-4 

Data  base  operator- 

characteristics,  8.4-3 
description,  8.4-3 
duties,  8.4-3 
skills,  8.4-3 

Data  base  query,  HELPs,  1.3-2  -  1.3.3 

Data  base  user: 

characteristics,  8.4-3 
duties,  8.4-4 

description,  8.4-3  -  8.4-4 
skills,  8.4-4 

Data  change: 

input  unburdening,  3.2-17 
interrupts  and  work  recovery, 

3.3- 9 

query  methods,  5.1-11 

Data  contingency  violation,  error 
feedback,  7.1-3,  7.1-11  -  7.1-12 


Data  deletion: 

input  unburdening,  3.2-17 
query  methods,  5.1-11 

Data  display: 

alphanumeric  displays,  2.1-2 
error  correction,  7.2-8 

Data  entry: 

alphanumeric  displays,  2.1-2 
alphanumeric  message  composition, 

4.1- 6,  4.1-9  -  4.1-10 
delimiters,  3.2-18 

graphics  displays,  4.2-7,  4.2-11 
HELPs,  1.3-2 
highlighting,  2.3-3 
input  unburdening,  3.2-2,  3.2-3, 

3.2- 13  -  3.2-19 

interrupts  and  work  recovery,  3.3-9 
system  entry,  4.1-6,  4.1-9  -  4.1-10, 

4.2- 7,  4.2-11 

user/operator,  4.1-6,  4.1-10,  4.2-7, 

4.2- 11 

Data  entry  and  handling,  3-1  -  3.3-11 

Data  entry  codes,  legal  entries, 

3.1- 8 

Data  entry  confirmation,  input  unbur¬ 
dening,  3.2-17 

Data  entry  error,  highlighting  of, 
2.3.3 

Data  entry  operator: 
characteristics,  8.4-2 
description,  8.4-2 
duties,  8.4-2 
skills,  8.4-2 

Data  entry  option,  input  unburdening, 

3.2- 18 

Data  entry  repetition,  error  correc¬ 
tion,  7.2-7 

Data  entry  sequence: 

error  feedback,  7.1-3,  7.1-10  - 

7.1- 11 

input  unburdening,  3.2-7,  3.2-14, 

3.2- 22  -  3.2-23 

Data  formats: 

alphanumeric  messages,  4.1-1  - 

4.1-11 

graphics  displays,  4.2-1  -  1.2-13 
input  unburdening,  3.2-15 
legal  entries,  3.1-12 


Data  handling  (see  data  entry  and 
data  entry  and  handling) 

Data  insertion,  error  feedback, 

7.1- 2,  7.1-8  -  7.1-9 

Data  modification,  query  methods, 

5.1- 2 

Data  omission,  error  feedback, 

7.1- 2,  7.1-7  -  7.1-8 

Data  processing: 
functions,  8.5-2 
methods,  8.4-1  -  8.4-4 
user/operator  type,  8.5-2 

Data  reentry,  error  correction, 

7.2- 4  -  7.2-5,  7.2-9 

Data  retrieval:  5-1  -  5.2-12 
query  methods,  5.1-1  -  5.1-18 
scope,  5-1 

Data  storage,  interrupts  and  work 
recovery,  3.3-6  -  3.3-7,  3.3-10 

Data  transcription,  input  unburden¬ 
ing,  3.2-2 

Data  transmission  rate: 

alphanumeric  control  methods, 

1.1-10 

command  stack,  1.1-13 
HELPs,  1.3-9  -  1.3-11 
input  unburdening,  3.2-17 
legal  entries,  3.1-12 
menu  size,  1.1-13 
query  methods,  5.1-10,  5.1-11, 

5.1-14 

Data  validation: 

input  unburdening,  3.2-17 
legal  entries,  3.1-13 

Data  verification: 

input  unburdening,  3,2-14 
interrupts  and  work  recovery, 

3.3-9 

query  methods,  5.1-2 


Definition  of: 

abbreviations  and  codes,  6.3-1  - 

6.3-3 

alphanumeric  control  methods,  1.1-1 

alphanumeric  displays,  2.1-1 

alphanumeric  messages,  4.1-1 

error  correction  and  recovery,  7.2-1 

error  feedback,  7.1-1 

full  language,  6.4-1 

glossaries,  6.5-1 

graphics  control  methods,  1.2-1 

graphics  displays,  2,2-1,  4.2-1 

HELPS,  1.3-1 

highlighting,  2.3-1 

input  unburdening,  3.2-1 

interrupts  and  work  recovery,  3.3-1 

legal  entries,  3.1-1 

operator,  8.1-1 

query  methods,  5.1-1 

query  structure,  5.2-1 

selective  highlighting,  2.3-1 

standard  terms,  6.2-1 

symbols,  6.1-1 

user,  8.1-1 

user/operator  configuration,  8.1-1 
Dialog: 

alphanumeric,  1.2-9 
cursor  control,  1.1-7,  1.1-14, 

1.2-18 

light  pen,  1.1-6,  1.1-12, 

1.1- 14,  1.2-10 
menu,  1.1-12, 

natural  language,  1.1-8,  1.1-15, 

5.1- 4,  5.1-12,  5.2-5 
question  and  answer,  1.1-4 
trackball,  1.2-11 
user-initiated,  1.1-7,  1.1-14, 

5.1-4,  5.1-13,  5.2-5 
voice  input,  1.1-15 

Differentiation,  highlighting,  2.3-3 

Digitization : 

graphics  displays,  4.2-9,  4.2-12 
methods,  1.2-17,  1.2-21,  1.2-26 


Decision-related  functions,  user/ 
operator  type,  8.5-2 

Default  values: 

error  feedback,  7.1-14 
glossaries,  6.5-4 
input  unburdening,  3.2-17 
legal  entries,  3.1-13 
query  methods,  5.1-11 
query  structure,  5.2-11 


Discriminability,  color,  6.3-15 

Display  accuracy: 

graphics  control  methods,  1.2-25, 

1.2- 27 

symbol  orientation,  1.2-29 

Display  linkages: 
data  entries,  3.1-15 
legal  entries,  3.1-9 

Display  parameters,  selection  of, 

1.2- 6~  1.2-28 
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Display  techniques:  2-1  -  2.3-18 
alphanumeric,  2.1-1  -  2.1-15  (see 
alphanumeric  displays) 
applications,  2-1 
graphics,  2.2-1  -  2.2-14  (see  ■< 
graphics  displays) 
highlighting,  2.3-1  -  2.3-18  (see 
highlighting) 
scope,  2-1 
sketching  on,  1.2-3 
touch  sensitive,  1.2-19 
tracing  on,  1.2-4 

Doctrine : 

abbreviations  and  codes,  6.3-6 
standard  terms,  6.2-5 

Drawing: 

advisory  comments,  2.2-14 
graphics  display,  2.2-9 

Entry  (see  data  entry  and  data  entry 
and  handling) 

Error  correction:  7.2-1  -  7.2-9 
advisory  comments,  7.2-6 
applications ,  7.2-2 
benefits,  7.2-3 
definition,  7.2-1 
methods,  7.2-4  -  7.2-6 
recommendations,  7.2-7  -  7.2-8 
use,  7.2-1 

Error  documentation,  7.1-14 

Error  feedback: 7.1-1  -  7.1-14 
applications,  7.1-2 
benefits,  7.1-5 
definition,  7.1-1 
methods,  7.1-6  -  7.1-13 
presentation,  7.1-14 
recommendations ,  7.1-14 
timing,  7,1-14 
use,  7.1-1 

Error  handling:  1.3-3,  7-1  -  7.2-9 
Alphanumeric  displays,  2.1-2 
HELPS,  1.3-3 
scope,  7-1 

Error  messages: 

alphanumeric  displays,  2.1-10 
content,  7.1-14 
recommendations,  2.1-11 

Error  recovery  (see  error  correc¬ 
tion) 


Error  reduction: 

alphanumeric  control  methods ,  1.1-3 
alphanumeric  displays,  2.1-3 
alphanumeric  message  composition, 

4.1- 3 

error  correction  and  recovery,  7.2-3 

feedback,  7.1-5 

glossaries,  6.5-3 

graphics  control  methods,  1.2-8 

graphics  displays,  2.2-4,  4.2-6 

HELPS,  1.3-4 

highlighting,  2.3-4 

input  unburdening,  3.2-4 

interrupts  and  work  recovery,  3.3-4 

query  methods,  5.1-3 

query  structure,  5.2-4 

standard  terms,  6.2-3 

symbols,  6.1-3 

user/operator  configuration,  8. 3-1 

Equipment  operator? 
characteristics,  8.4-1 
description,  8.4-1  -  8.4-2 
duties,  8.4-1 
skills,  8.4-1  -  8.4-2 

Examples : 

abbreviations,  6.3-2,  6.3-10,  6.3-11 
codes ,  6 . 3-2 

commands,  6.5-1  -  6.5-59 
legal  entries,  3.1-7 

Field  length,  violation,  7.1-2,  7.1-9  - 

7.1- 10 

Fixed  alphanumeric  displays:  2.1-4  - 

2.1- 15 

advisory  comments,  2.1-12  -  2.1-14 
methods,  2.1-4  -  2.1-10 
recommendations,  2.1-11 

Fixed  formats: 

alphanumeric  displays,  2.1-12, 

2.1- 14 

alphanumeric  messages,  4.1-2 

Fixed  function  keys: 

advisory  comments,  1.1-11 
alphanumeric  controls,  1.1-5 
cursor  control,  1.2-18 
input  unburdening,  3.2-7,  3.2-15, 

3.2- 23  -  3,2-24 
query  methods,  5.1-11 

Flashing,  highlighting,  2.3-8,  2.3-16 


B-6 


Flow  charts 

advisory  comments,  2.2-12  -  2.2-13 
graphics  displays,  2.2-7 

Formats 

input  unburdening,  3.2-18 
legal  entries,  3.1-2 
recognition ,  3.2-11 
scanning  purposes,  2.1-13 

Form  fillings 

advisory  comments,  1.1-11 
alphanumeric  control  methods, 

1.1- 4 

alphanumeric  messages,  4.1-4  - 

4.1- 5,  4.1-9 
HELPS,  4.1-5,  4.1-9 

input  unburdening,  3.2-11,  3.2-25  - 

3.2- 26 

legal  entries,  4.1-4,  4.1-9 
query  methods,  5.1-5,  5.1-15 
query  structure,  5.2-6 
standard  terms,  6.2-2 

Free  form  drawings 
creation,  4.2-5 
graphics  displays,  2.2-2 

Free  text: 

alphanumeric  display,  2.1-10 
alphanumeric  messages,  4.1-2 
recommendations ,  2 . 1-11 
variable  alphanumeric  display, 

2.1-15 

Frequency  polygons 

advisory  comments,  2.2-11  -  2.2-12 
graphics  displays,  2.2-6 

Full  language:  6.4-1  -  6.4-6 
applications,  6.4-2 
benefits,  6.4-3 
definition,  6.4-1 
methods,  6.4-4 

recommendations,  6.4-5  -  6.4-6 
style,  6.4-5 
use,  6.4-1 

versus  abbreviations,  6.3-7  -  6.3-8, 

6.3- 11 

versus  codes,  6.3-3,  6.3-13 
versus  codes  and  abbreviations, 

6.4- 5 

Full  text  (see  full  language) 

Functional  assignment: 

user/operator  capabilities,  8.5-1 
user/operator  training,  8.5-1 


Function  keys:  (see  also  fixed  func¬ 
tion  keys  and  variable  function  keys) 
advisory  comments,  1.1-11  -  1.1-12 
alphanumeric  control,  1.1-5 
overlays/underlays,  1.1-5,  1.1-12 
query  structure,  5.2-11 

Glossaries:  6.5-1  -  6.5-59 
applications,  6.5-2 
benefits,  6.5-3 
definition,  6.5-1 
methods,  6.5-4 
presentation,  6.5-1 
operation,  by  potential  command,  by 
recommended  command,  6.5-19  -  6.5-32 
potential  command,  by  operation,  by 
recommended  command,  6.5-33  -  6.5-59 
recommended  command,  by  operation,  by 
potential  command,  6.5-6  -  6.5-18 
rules,  6.5-5 

Grammatical  symbols: 
applications,  6.1-2 
definition,  6.1-1 

Graph,  advisory  comments,  2.2-11 

Graphics  commands: 
complexity,  1.2-24 
multiple  screen  displays,  1.2-24 
number  of,  1.2-24 
selection  of,  1.2-2,  1.2-24 
usage  rate,  1.2-24 

Graphics  composition  aids:  4.2-1  - 

4.2- 13 
use,  4.2-1 

Graphics  control  methods ;  1.2-1  - 

1.2- 29 

applications,  1.2-2  -  1.2-7 
benefits,  1.2-8 
definition,  1.2-1 
digitization,  1.2-26 
display  accuracy,  1.2-25,  1.2-26, 

1.2-27,  1.2-29 

display  parameters,  1.2-6,  1.2-28 
drawing  on  a  display,  1.2-3 
errors,  1.2-8 

methods  for  using,  1.2-9  -  1.2-24 
multiple-screen  displays,  1.2-28 
number  of  display  parameters,  1.2-28 
orienting  symbols,  1.2-7,  1.2-29 
recommendations,  1.2-23  -  1.2-29 
selecting  commands,  1.2-2 
sketching,  1.2-25 
speed,  1.2-25,  1.2-27,  1.2-29 
tracing,  1.2-4,  1.2-26 
use,  1-1 

user/operator  fatigue,  1.2-8 
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Information  transfer,  HELPs,  1.3-8 

Input : 

applications  for  unburdening, 

3.2- 2  -  3.2-3,  3.2-14 
legal  entry,  3.1-15 
user/operator  type,  8.5-2 

Input  unburdening:  (see  also  unbur¬ 
dening  of  input)  3.2-1  -  3.2-27 
advisory  comments,  3.2-20  -  3.2-27 
applications  3.2-2  -  3.2-3 
benefits,  3,2-4 
definition,  3.2-1 
methods,  3.2-5  -  3.2-12 
recommendations,  3.2-13  -  3.2-19 

Interrupts  and  work  recovery: 

3.3-1  -  3.3-11 

advisory  comments,  3.3-10  -  3.3-11 
applications,  3,3-2  -  3.3-3 
benefits,  3.3-4  -  3.3-5 
definition,  3.3-1 
methods,  3.3-6  -  3.3-7 
recommendations,  3.3-8  -  3.3-9 
use,  3.3-1 

Jargon,  computer,  7.1-14 

Job  satisfaction,  user/operator 
configuration,  8.3-1 

Joystick: 

detent,  1.2-15 

direct  positioning,  1.2-12 

graphics  control  method,  1.2-12  - 

1.2- 16 

graphics  displays,  4.2-9,  4.2-12 
pieaoelectric,  1.2-16 
relative  positioning,  1.2-13  - 

1.2-14 

stepping,  1.2-15 
strain  gauge,  1.2-16 

Keyboards : 

abbreviations  and  codes,  6.3-6 
full  language,  6.4-4 
graphics  control  methods,  1.2-2Q 
symbol  selection,  6.1-4 

Keys,  graphics  control  methods, 

1.2-17  -  1.2-18 

Language  structure: 
hierarchical,  6.2-5 
standard  terms,  6.2-5 

Legal  entries:  3.1-1  -  3.1-16 
advisory  comments,  3.1-15 


Legal  entries,  cont'd: 

applications,  3.1-2  -  3.1-3 
benefits,  3.1-4 
code  design,  3.1-2  -  3.1-3 
definition,  3.1-1 
format,  3.1-2 
form  filling,  4.1-4 
glossary,  6.5-2 
methods,  3.1-5  -  3.1-10 
recommendations,  3.1-11 
standard  terminology,  3.1-3 
use,  3.1-1 

valid  and  incorrect,  3.1-2 

Light  gun  (see  light  pen/light  gun 
and  also  light  pen  dialog) 

Light  pen/light  gun: 

graphics  control  method,  1.2-10 
graphics  displays,  4.2-9,  4.2-12 
input  unburdening,  3.2-20 

Light  pen  dialog: 

advisory  comments,  1.1-12,  1.1-14 
alphanumeric  control  method,  1.1-6 

Line  drawing: 

advisory  comments,  2.2-14 
graphics  display,  2.2-9 

Lists: 

alphanumeric  displays,  2.1-4  -  2.1 
2.1-13 

recommendations,  2.1-11 

Machine  translation,  input  unburden¬ 
ing,  3.2-11,  3.2-16,  3.2-26 

Manual  operation,  versus  automatic, 
8.5-1 

Manuals: 

data  entry,  3.1-15 
glossaries,  6.5-4 
legal  entries,  3.1-10 

Manual  versus  automatic  operation, 
user/operator  experience,  8.5-1 

Map  overlay: 

advisory  comments,  2.2-3 

creation  of,  4.2-3 

graphics  displays,  2.2-8  -  2.2-9 

Maps : 

advisory  comments,  2.2-13 

creation  of,  4.2-2 

graphics  displays,  2.2-8  -  2.2-9 

Meaning fulness,  full  language,  6.4-5 


8-9 


Measures,  input  unburdening,  3.2-18, 

3.2-20 

Menus: 

alphanumeric  displays.  2.1-2,  2.1-13 
alphanumeric  message  composition, 

4.1- 6,  4.1-10  -  4.1-11 
glossaries,  6.5-4 

graphics  displays,  4.2-8,  4.2-12 
hierarchical  structure,  5.1-14 

5.1- 15 

input  unburdening,  3.2-5,  3.2-21 
legal  entries,  3.1-5,  3.1-15 
query  methods,  5.1-5,  5.1-13  - 

5.1- 15 

query  structure,  5.2-6 
standard  terms,  6.2-2 

Menu  selection: 

advisory  comments,  1.1-12  -  1.1-13 
alphanumeric  control  method,  1.1-6 

Menu  size,  data  transmission  rate, 

1.1- 13 

Message  composition  aids:  4-1  - 

4.2- 13 

Message  content,  feedback,  7.1-14 
Message  generation,  HELPs,  1.3-3 

Message  integrity,  graphics  displays, 

4.2- 6 

Message  receipt,  interrupts  and  work 
recovery,  3.3-2 

Messages : 

full  language,  6.4-2 
record  of,  8.5-3 

Methods  for: 

abbreviations  and  codes,  6.3-6 
alphanumeric  controls,  1.1-4  -  1.1-8 
alphanumeric  displays,  2.1-4  - 

2.1- 10 

alphanumeric  message  composition 

4.1- 4  -  4.1-7,  4.1-8 

data  processing,  8.4-1  -  8.4-4 
error  correction  and  recovery, 

7.2- 4  -  7.2-6 

error  feedback,  7.1-6  -  7.1-14 
full  language,  6.4-4 
glossaries,  6.5-4 
graphics  control,  1.2-9  -  1.2-22 
graphics  displays,  2.2-5  -  2.2-9 
graphics  displays  composition, 

4.2- 7  -  4.2-9.  4.2-10 


Methods  for,  cont'd: 

HELPS,  1.3-5  -  1.3-8 
highlighting,  2.3-5  -  2.3-11 
input  unburdening,  3.2-5  -  3.2-12 
interrupts  and  work  recovery,  3.3-6 

3.3-7 

legal  entries,  3.1-5  -  3.1-10 
queries,  5.1-4  -  5.1-8 
query  structure,  5.2-5  -  5.2-9 
standard  terms,  6.2-4 
symbol  selection,  6.1-4 

Mnemonics: 

definition,  6.3-1 
examples,  6.3-2 

Mouse,  graphics  control  method,  1.2-11 

Multiple  displays,  interrupts  and  work 
recovery,  3.3-6,  3.3-10 

Multiple  screen  displays,  scrolling, 

2.1- 14 

Multiple  sensory  channels,  interrupts 
and  work  recovery,  3.3-6,  3.3-10 

Natural  language: 

advisory  comments,  1.1-15 
alphanumeric  control  method,  1.1-8 
query  methods,  5.1-4,  5.1-13 
query  structure,  5.2-2 
voice  input,  5.1-6,  5.1-16,  5.2-7 

Number  of  commands,  alphanumeric  con¬ 
trol  methods,  1.1-9 

Operation,  automatic  versus  manual, 
8.5-1 

Operational  time,  reduction  of,  1.2-8 

Operator,  (see  also  user/operator) 
definition,  8,1-1 

Organization  chart,  graphics  display, 

2.2- 7 

Output : 

abbreviations ,  6.3-11 
full  language,  6.4-3 
functions  and  user/operator  type, 
8.5-2 

Overlays: 

function  keys,  1.1-5,  1.1-12 
maps,  2.2-8  -  2.2-9.  2.2-13 

Personal  files: 

alphanumeric  displays,  2.1-10 
reconaendations,  2.1-11 
user/operator,  8.5-3 


Personnel  (see  user/operator) 

Pictorial  symbols: 
applications,  6.1-2 
definition,  6.1-1 

Pie  charts: 

advisory  comments,  2.2-12 
graphics  displays,  2.2-7 

Positioning,  highlighting,  2.3-11, 

2.3- 18 

Prestructured  formats,  alphanumeric 
displays,  2.1-5  -  2.1-9 

Priority  information,  highlighting, 

2.3- 2 

Priority  messages/tasks,  interrupts 
and  work  recovery,  3.3-2,  3.3-9 

Prompts : 

error  correction,  7.2-7 
error  feedback.  7.1-6 
glossaries,  6.5-4 
input  unburdening,  3.2-11,  3.2-15, 

3.2-18,  3.2-27 

query  methods,  5.1-4,  5.1-11 
query  structure,  5.2-5 

Protected  areas,  input  unburdening, 

3.2- 19 

Pulsating,  highlighting,  2.3-8 
Punctuation,  abbreviations,  6.3-11 

Quantitative  data,  graphics  displays, 

2.2- 2,  4.2-4 

Queries: 

data  base,  1.3-2  -  1.3-3 
full  language,  6.4-2 
number  of,  5.1-10 

Query  language: 

advisory  comments,  5.1-13 

voice  input,  5.1-6,  5.1-15,  5.2-7 

user-initiated,  5.1-4,  5.1-13,  5.2-5 

Query  methods:  5.1-1  -  5.1-18 

advisory  comments,  5.1-13  -  5.1-18 
applications,  5.1-2 
benefits,  5.1-3 
definition,  5.1-1 
methods  for  implementing,  5.1-4  - 
5.1-9 

recommendations,  5.1-9  -  5.1-12 
use,  5.1-1 


Query  structure:  5.2-1  -  5.2-12 
advisory  comments,  5.2-11  -  5.2-12 
applications,  5.2-2 
benefits,  5.2-4 

complexity,  5.2-2  -  5.2-3,  5.2-10 
definition,  5.2-1 
methods,  5.2-5  -  5.2-9 
parameters,  5.2-11  -  5.2-12 
recommendations,  5.2-10 
use,  5.2-1 

Question  and  answer  dialog: 
advisory  comments,  1.1-11 
alphanumeric  control  method,  1.1-4 
query  methods,  5.1-7,  5.1-17 
query  structure,  5.2-8 

Recommendations  for: 

abbreviations  and  codes,  6.3-7  - 

6.3-15 

alphanumeric  controls,  1.1-9  -  1.1-10 
alphanumeric  displays,  2.1-11 
alphanumeric  message  composition, 

4.1- 8 

codes,  6.3-12  -  6.3-15 

data  retrieval,  5.1-11  -  5.1-12, 

5.2- 10  -  5.2-12 

error  correction  and  recovery,  7.2-7  - 

7.2- 8 

error  feedback  -  7.1-14 
full  language,  6.4-5  -  6.4-6 
glossaries,  6.5-5 

graphics  controls,  1.2-23  -  1.2-29 
graphics  displays,  2.2-10 
graphics  displays  composition,  4.2-10 
HELPS,  1.3-9  -  1.3-11 
highlighting,  2.3-12  -  2.3-13 
input  unburdening,  3.2-13  -  3.2-19 
interrupts  and  work  recovery, 

3.3- 8  -  3.3-9 
legal  entries,  3.1-11 

query  methods,  5.1-9  -  5.1-12 
query  structure,  5.2-10 
selective  highlighting,  2.3-12  - 

2.3- 13 

standard  terms,  6.2-5  -  6.2-7 
symbols,  6.1-5  -  6.1-10 
user/operator  configuration,  8.5-1  - 
8.5-3 

Relationship  display,  graphics  dis¬ 
plays,  2.2-2 

Reports,  abbreviations  in,  6.3-11 

Reverse  display,  highlighting,  2.3-6, 

2.3- 15 


■  I 


Scanner/digitizer,  graphics  control 
method,  1.2-21 

Screen  area,  highlighting,  2.3-3 

Screen  size,  style  considerations, 

6.4- 6 

Scrolling,  multiple  screen  displays, 

2.1- 14 

Security: 

interrupts  and  work  recovery,  3.3-9 
query  methods,  5.1-3 

Selective  highlighting  (see  high¬ 
lighting) 

Shape,  codes,  6.3-3 

Shoe  box  files: 

alphanumeric  displays ,  2.1-10 
recommendations,  2.1-11 

Simultaneous  tasks,  interrupts  and 
work  recovery,  3.3-3 

Sketching,  graphics  display,  2.2-2 

Speed,  graphics  control  methods, 

1.2- 25,  1.2-27 

Special  features,  highlighting, 

2.3- 2 

Software : 

abbreviations  and  codes,  6.3-6 
full  language,  6.4-4 
symbol  selection  6.1-4 

Standard  terms:  6.2-1  -  6.2-7 
abbreviations,  6,3-7  -  6.3-8 
applications,  6.2-2 
benefits,  6.2-3 
definition,  6.2-1 
glossary,  6.5-2,  6.5-5 
legal  entries,  3.1-3,  3.1-14 
methods,  6.2-4 

recommendations,  6.2-5  -  6.2-7 
use,  6.2-1 

Storage : 

HELPS,  1.3-10  -  1.3-11 
input  unburdening,  3.2-19 

Style  considerations: 
full  language,  6.4-5 
screen  size,  6.4-6 

Symbology  and  terminology,  >3-1  - 

6.5- 70 


Symbol  sets  (see  symbols) 

Symbols:  6.1-1  -  6.1-10 
abbreviations  and  codes,  6.3-1 
alphabetic,  6.1-1,  6.1-2 
applications,  6.1-2 
arabic,  6.1-1,  6.1-2 
benefits,  6.1-3 
classes,  6.1-1 
codes,  6.3-3,  6.3-13 
confusions,  6.1-8,  6.1-9 
definition,  6.1-1 
definitions  for,  6.1-6 
discriminability ,  6.1-8  -  6.1-9 
glossary,  6.5-5 
grammatical,  6.1-1,  6.1-2 
graphic,  6.1-1,  6.1-2, 
graphics  display,  1.2-5,  6.3-3 
input  unburdening,  3.2-15,  3.2-17, 

3.2- 18 

legal  entries,  3.1-13,  3.1-14 
legibility,  6.1-8  -  5.1-10 
methods,  6.1-4 

orientation,  1.2-7,  1.2-27,  1.2-29 
pictorial,  6.1-1,  6.1-2 
query  structure,  5.2-10,  5.2-11 
recommendations,  6.1-5  -  6.1-7 
selection  of,  6.1-7  -  6.1-8 
special,  6.1-1,  6.1-2 
specification  rate,  1.2-29 
standard  usage,  6.1-7 
use,  6-1 

Surrounding,  highlighting,  2.3-9, 

2.3- 17 

Syntax,  glossaries,  6.5-2,  6.5-5 

System  applications,  user/operator 
characteristics,  8.5-2 

System  complexity,  HELPs,  1.3-10  - 

1.3-11 

System  conf igurat ion/re con f iguration , 
interrupts  and  work  recovery,  3.3-2 

System  failure,  interrupts  and  work 
recovery,  3.3-2 

System  function,  usor/operator  type, 

8.5-2 

System  initialization/startup,  inter¬ 
rupts  and  work  recovery  3.3-2,  3.3-9 


System  operation: 

automatic  versus  manual,  8.5-1 
user/operator  characteristics, 

8.4-1  -  8.4-4 
user/operator  type,  8.5-2 

System  search,  error  correction, 

7.2-5  -  7.2-6,  7.2-9 

System  startup,  interrupts  and  work 
recovery,  3.3-7,  3.3-11 

System  throughput  rate  (see  through¬ 
put  rate) 

System  user: 

characteristics,  8.4-4 
description,  8.4-4 
duties,  8.4-4 
skills,  8.4-4 

Tagging,  highlighting,  2.3-10,  2.3-17 

Target  identification,  highlighting, 

2.3-3 

Tasks,  concurrent,  3.3-3 

Terminology  (see  terms) 

Terms: 

consistency,  6.2-5,  6.2-6,  6.2-7 

definition,  6.2-7 

difficulty,  6.2-5 

flexibility,  6.2-7 

format ,  6 . 2-6 

length,  6.2-5,  6.3-9 

numbers  of,  6.2-6 

selection  of,  6.2-5 

usage,  6.2-6  -  6.2-7 

Text  (see  language) 

Throughput  rate: 

abbreviations  and  codes,  6.3-5 
alphanumeric  control  methods,  1.1-3 
alphanumeric  displays,  2.1-3 
alphanumeric  message  composition, 

4.1- 3 

error  correction  and  recovexy, 

7.2- 3 

error  feedback,  7.1-5 

glossaries,  6.5-3 

graphics  control  methods,  1.2-8 

graphics  displays,  2.2-4 

graphics  displays  cosmos ition,  4.2-6 

HELPS,  1.3-4 

highlighting,  7.3-4 

input  unburdening,  3.2-4 


Throughput  rate,  cont'd: 

interrupts  and  work  recovery,  3.3-4 

legal  entries,  3.1-4 

query  methods,  5.1-3 

query  structure,  5.2-4 

standard  terms,  6.2-3 

symbols,  6.1-3 

user/operator  configuration,  8.3-1 
Timing: 

error  correction,  7.2-8 
error  feedback.  7.1-14 

Topographic  data,  graphics  displays, 

2,2-2 

Touch  sensitive  surface: 

graphics  control  method,  1.2-19, 

1.2-22 

graphics  displays,  4.2-9,  4.2-13 

Touch  screen,  input  unburdening, 

3.2- 9,  3.2-25 

Trackball: 

graphics  control  method,  1.2-11 
graphics  displays,  4.2-9,  4.2-12 

Transmission  rate,  commands,  l.l-lo 

Trend  analysis: 

advisory  comments,  2.2-11  -  2.2-12 
graphics  display,  2.2-6 

Type  font,  characteristics,  6.1-9  - 
6.1-10 

Unburdening  of  input:  (see  also  input 
unburdening)  3.2-1  -  3.2-27 
advisory  comments,  3.2-20  -  3.2-27 
applications,  3.2-2  -  3.2-3 
benefits,  3.2-4 
definition,  3.2-1 
methods,  3.2-5  -  3.2-12 
recommendations,  3.2-13  -  3.2-19 
use,  3.2-1 

Underlays,  function  keys,  1.1-5,  1.1-12 

Underlining,  highlighting,  2.3-7, 

2.3- 15 

Unusual  values,  highlighting,  2.3-2 

Upper  case  letters: 
abbreviations,  6.3-11 
highlighting,  2.3-6 

Usage  frequency,  query  methods,  5.1-10, 
5.1-11 


Usage  rate,  graphics  commands,  1.2-24 

User  (see  also  user/operator) ,  defi¬ 
nition,  8.1-1 

Use  sequence,  legal  entries,  3.1-12, 

3.1-15 

User/ operator  characteristics:: 
alphanumeric  control  methods, 

1.1-9  -  1.1-10 
data  base  operator,  8.4-3 
data  base  user,  8.4-3 
data  entry  operator,  8.4-2 
equipment  operator,  8.4-1 
system  user,  8.4-4 

User/operator  configuration:  8-1  - 

8.5-3 

applications,  8.2-1  -  8.2-4 
benefits,  8.3-1 
categories,  8.4-1  -  8.4-4 
definition,  .1-1 
recommendations,  8.5-1  -  8.5-3 
scope,  8-1 

User/operator  description: 
data  base  operator,  8.4-3 
data  base  user,  8.4-3  -  8.4-4 
data  entry  operator,  8.4-2 
equipment  operator,  8.4-1  -  8.4-2 
system  user,  8.4-4 

User/operator  duties: 

data  base  operator,  8.4-3 
data  base  user,  8.4-4 
data  entry  operator,  8.4-2 
equipment  operator,  8.4-1 
system  user,  8.4-4 

User/operator  error: 
abbreviations,  6.3-9 
code  length,  6.3-15 
code  sets,  6.3-15 

interrupts  and  work  recovery,  3. 3-9 

Usor/operator  experience: 

alphanumeric  control  methods,  1.1-9 
automatic  versus  manual  operations, 

8.5-1 

code  design,  6.3-13 

code  sets,  3.1-2 

command  language,  1.1-14 

error  correction,  7.2-9 

HELPS,  1.3-9  -  1.3-11 

input  unburdening,  3.2-14,  3.2-18 

legal  entries,  3.1-12,  3.1-15 

menu  selection,  1.1-12 


User/operator  experience,  cont'd: 
natural  language,  1.1-15 
query  methods,  5.1-9,  5.1-11 
query  structure,  5.2-10,  5.2-11 
terminology,  6.4-5 
user/operator  configuration,  8.3-1 
valid  codes,  3.1-2 

User/operator  frustration: 

alphanumeric  control  methods,  1.1-3 
alphanumeric  message  composition, 

4.1-3 

graphics  control  methods,  1.2-8 
interrupts  and  work  recovery,  3.3-4  - 
3.3-5 

User/operator  skills:  (see  also  user/ 
operator  experience) 
data  base  operator,  8.4-3 
data  base  user,  8.4-4 
data  entry  operator,  8.4-2 
equipment  operator,  8.4-1  -  8.4-2 
system  user,  8.4-4 

User/operator  sophistication  (see 
user/operator  experience) 

User/operator  tasks:  8.2-1  -  b.2-4 
aggregate  data,  8.2-2 
calculate,  8.2-2,  8.2-3 
data  correction,  8.2-2 
data  entry,  4.2-11,  8.2-1  -  8.2-2 
data  update,  8.2-2 
data  parameters,  8.2-4 
error  correction,  7.2-5  -  7.2-8 
evaluate  results,  8.2-3 
formulate  processing  steps,  8.2-3 
formulate  processing  strategy,  8.2-3 
generate  reports,  8.2-4 
interaction,  8.5-1 
log-on/ log-off,  8.2-1 
monitor  operations,  8.2-1 
set  up  equipment  8.2-1 
superimpose  data,  8.2-3 
system  initialization,  8.2-1 
tabulate  data,  8.2-2 
translate,  8.2-3 
workstation  coordination,  8.2-1 

User/operator  training: 

error  correction  and  recovery,  7.2-3 
error  feedback,  7.1-5 
query  methods ,  5.1-3 
query  structure,  5.2-4 

User/operator  type,  system  function, 

8.5-2 
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Valid  entries,  3.1-2 


Variable  alphanumeric  displays: 
advisory  comments,  2.1-15 
methods,  2.1-10 
recommendations,  2.1-11 


Variable  format,  alphanumeric  mes¬ 
sages,  4.1-2 


Variable  function  keys: 
advisory  comments,  1.1-12 
alphanumeric  control  methods,  1.1-5 
input  unburdening,  3.2-8,  3.2-24 


Vocabulary  (see  terms) 


Voice  input: 

advisory  comments,  1.1-15 
alphanumeric  control  method,  1.1-8 
natural  language,  5.1-6,  5.1-16, 
5.2-7 

query  language,  5.1-6,  5.1-15,  5.2-7 
query  methods,  5.1-6,  5.1-15  - 
5.1-16 

query  structure,  5.2-7 


Warning,  highlighting,  2.3-3 


Work  interrupts  (see  interrupts  and 
work  recovery 


Work  recovery  (see  interrupts  and 
work  recovery) 
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